Ода за паметта

Сегментните регистри са въведени в I8086 поради невъзможността да се адресира 1MB с шестнайсетбитово отместване. Приело се е в сегментен регистър да се записва адрес от паметта, който е кратен на 16, т.е. младшите четири бита са нули и поради това могат да не се съхраняват в регистъра. При образуването на физическия адрес процесорът измества стойността на сегментния регистър четири пъти наляво и прибавя отместването, за да получи 20-битов адрес. Поради тази концепция се е оказвало, че всеки един физически адрес може да се представи като комбинация от параграфен адрес и отместване по 65536 различни начина. Ето например за физическия адрес 16164h четири от тях: 1070:5A64, 1071:5A54, 1616:0004 (каноничен адрес), 1610:0064. Това не е недостатък, а предимство, което позволява по-ефективно разпределение на паметта от 1MB в реален режим. Тъй като всеки сегментен регистър съдържа параграфен адрес на област от паметта с размер 64К, тази област се наричаше сегмент, а параграфният адрес – още сегментен адрес.

Заедно с появата на защитения режим в I80286 се промени изцяло и принципът за сегментация на паметта. Сега вече между числото, зареждано в сегментен регистър и областта от паметта, която може да се адресира чрез него, няма никаква пряка връзка: стойността в сегментния регистър е индекс към осембайтово описание на сегмент. За изграждането на таблиците се грижи ОС и приложението губи всякаква представа на какъв физически адрес се намира. Не може да се каже дори дали част от адресираната и достъпна за едно приложение оперативна памет е във физическата памет, а не временно преместена на външен носител, например диск. Този модел на паметта решава множество проблеми, които възникваха в реален режим и най-големите от тях са фрагментацията на паметта и адресирането извън логическите граници на сегмента. Когато едно приложение активно заделя и освобождава памет (чрез повиквания към DOS или по собствена вътрешна логика от един по-голям буфер памет) идва момент, когато, макар общата свободна памет да е по-голяма от заявения обем, няма достатъчно голямо „парче“, което да удовлетвори заявката. В тази ситуация драйверът на паметта в защитен режим на ОС просто ще пренареди сегментите в линейната памет, ще промени техните дескриптори по съответния начин и ще обедини „парчетата“ в един голям блок. Приложението дори няма да усети че такова нещо е било извършено. Вторият проблем се появяваше, когато в програмата има грешка; тогава процесорът просто се обръщаше към указания адрес и програмата работеше с погрешни данни. При запис можеше да се получи разрушаване на данните на програмата или дори на кода . Всичко това създаваше огромни главоболия на програмистите, които с дни трасираха програмите си, за да открият някаква мъничка смехотворна грешчица, и огромни главоболия на потребителите, които губеха резултатите от часове усилен труд, ругаеха програмистите и понякога дори им се налагаше да преинсталират цялата система начисто. В защитен режим, където типът и размерът на всеки сегмент се задават явно, процесорът отказва достъпа още при първото срещнато невалидно обръщение.

С появата на 32-битовите процесори (I80386) отпадна още едно голямо ограничение, което много спъваше работата по големи проекти: максималният размер на сегмент да бил 64К. Това ограничение се заобикаля сравнително лесно (в реален режим се преминава към следващите 64К, а в защитен – към следващия по номер селектор, ако ОС е написана по съответния начин), но трябва да съществуват специални функции на ОС за заемане и освобождаване на големи блокове и непрекъснато да се следи дали има необходимост да се смени селекторът. Всичко това, според мен, е много изнервящо и замаскира голяма част от истинския проблем в системнозависими (и недомислени) задължителни действия, които се пишат от приложение на приложение. В I80386 обаче един-единствен сегмент може да съдържа 4GB код или данни без никакви проблеми. Изчезват оплакванията на компилаторите, че кодът бил станал твърде голям (което принуждава програмиста да дели изкуствено логически единен модул) или че данните били станали твърде много (който проблем не се решава, защото повечето компилатори разрешават само един глобален сегмент за данни, а и стекът за локалните данни не е неизчерпаем). Изчезват и оплакванията на приложенията, че файлът бил твърде голям, при все че има свободна памет още с мегабайтове.

Много дълго време операционните системи си оставаха 16-битови, въпреки че работеха на 32-битови процесори. I80386 беше обявен през 1985 и излезе през 1987 година. Оттогава до появата на Windows 95 през 1996 година на пазара се появиха няколко версии на DOS и Windows, които си останаха чисто 16-битови операционни системи. На въпроса защо така се отговаряше, че съществувало огромно количество стари програми, които трябвало било да се поддържат още. Появявата на Windows NT и Windows 95 обаче опровергава този аргумент – те поддържат на 100% старите приложения (DOS-овските – дори по-добре от 16-битовата Windows 3.11); освен това за много кратко време всички производители на софтуер пуснаха на пазара нови версии на продуктите си, които използват новите средства на Windows 95. Освен това се появи и OS/2 2.0, една много добра 32-битова ОС, която не можа да получи голямо разпространение по причини, които нямат никаква връзка с приложното програмиране – потребителите купуваха Windows, защото бяха свикнали с нея и защото Microsoft водеше много агресивна рекламна политика, а програмистите си скубеха косите от яд и ругаеха Бил Гейтс. Слава богу, с появата на Windows 95 това свърши. Windows 95 реализира истинска многозадачност, поддържа на 100% старите 16-битови приложения, осъществява много добра виртуализация и въвежда допълнителни средства, които до този момент изобщо не съществуваха. Новите програми за Windows 95 използват плоския модел на паметта, макар това да орязва силата на процесора да лови програмни грешки много близо до мястото на възникване. Като реализация и стабилност OS/2 остава по-добра от Windows, но просто не можа да пробие на пазара. Жалко! Microsoft закъсня с десет години, но чрез агресивна реклама (и дори незаконни способи, заради които бе съдена) си е извоювала мястото на най-голям създател и разпространител на софтуер в света.

Като че ли уроците от миналото са вече научени. AMD проектират архитектурата x86-64 (вж. глава X) като надстройка на x86, щото преминаването към нова 64-битова платформа да стане бързо и без много инвестиции. Архитектурата IA-64 е несъвместима с x86, но в Itanium (първият IA-64 процесор) е вградена и IA-32 като паралелна архитектура. Преминаването към IA-64 ще изисква повече инвестиции от преминаването към x86-64. Големите софтуерни компании обаче вече са готови със софтуерни продукти, които да използват новите платформи – това са Windows-64 за Itanium и версия на Linux за Hammer (първия x86-64 процесор).

Десетгодишното закъснение е преодоляно и забравено. Сега компаниите бързат да наваксат пропуснатото тогава и да осигурят печалбите си поне за десетилетие – до появата на 128-битови архитектури.