Обмеження пам’яті в 16, 32 та 64 бітних системах


17

Теоретичні межі пам’яті в 16, 32 та 64 бітових машинах такі:

  • 16 біт = 65 536 байт (64 кілобайт)

  • 32 біт = 4 294 967 296 байт (4 гігабайти)

  • 64 біт = 18,446,744,073,709,551,616 (16 екзабайт)

Я пам'ятаю з DOS / Windows 3.11 дня, що 16-бітну пам'ять можна розділити на сегменти, щоб 16-бітна машина могла отримати доступ до більшої кількості пам'яті, ніж 64 кілобайти.

У мене є машина з 16 ГБ пам'яті, і я подвійний завантаженням 32-бітної операційної системи та 64-бітної операційної системи. Я можу отримати доступ до всіх 16 Гб із 64-бітових, але лише 3,21 ГБ в 32-бітних.

Отже, моє запитання полягає в тому, що якщо 16-бітові операційні системи дозволяють отримати більше, ніж 64 КБ доступ до пам'яті за рахунок сегментування пам'яті, чому 32-бітні машини не слідкують за тим же самим учасником?

Відповіді:


15

Вони так називаються розширення фізичної адреси (PAE) . Ось список ОС Windows та їх максимальна пам'ять; будь-яка 32-бітова система, що забезпечує більше 4 ГБ оперативної пам’яті, використовує PAE для доступу до пам’яті (наприклад, 32-бітний Windows 2003 R2 Datacenter дозволяє отримати 128 ГБ оперативної пам’яті).


Насправді Windows 8 потребує процесора, здатного на PAE, у мінімальних вимогах .


Щоб вирішити ваше "незареєстроване" питання про те, чому ваша 32-бітна ОС не може отримати доступ до оперативної пам'яті, якщо вона існує: Ліцензування. Вони вирішили не дозволяти оперативній пам'яті перевищувати 4 Гб для своїх 32-бітних ОС, якщо ви не заплатите за видання центру даних (саме тому вони продають видання центру даних; якщо вам потрібна стільки оперативної пам'яті, ви, швидше за все, можете дозволити собі витратити більше гроші на ОС).


Ах, я чув про ПАЕ раніше, але ніколи цього не досліджував. Здається, він широко використовується в архітектурі сервера, тому, схоже, не застосовується до 32-бітної установки Windows 7, оскільки в списку зазначено, що W7x86 дозволяє використовувати до 4 Гб
Меттью Лейтон

1
@ 0xC0000022L, щоб бути справедливим, я додав ліцензійну частину як редагування після його коментаря, але через 4-х хвилинне вікно редагування виглядає так, що я розмістив його, перш ніж він опублікував коментар.
Скотт Чемберлен

1
PAE вимагає роботи таблиці перемикачів сторінок для роботи, і це дорого з точки зору продуктивності.
vonbrand

3
Це міф. Накладні витрати через ПАЕ невеликі. І якщо вам не подобається PAE, ви справді ненавидите x64, тому що структура таблиці сторінок на x64 виглядає так само, як PAE, лише з доданим ще одним рівнем таблиці вгорі та ще бітами для PFN в PxE.
Джеймі Ханрахан

1
PAE не "було видалено в Windows 7, тому що він більше не потрібен", він все ще присутній в Windows 7 x86 - він просто там за замовчуванням, а не для того, щоб робити вибір.
Джеймі Ханрахан

13

Замість того, щоб пояснювати це сам, я дозволю тому, хто повинен підтримувати ядро ​​з підтримкою PAE, висловитись своїми чарівними способами, Лінус Торвальдс

Також пам’ятайте, що підтримка PAE у 32-бітних версіях Windows надається за багато грошей. XP навіть не зможе нормально використовувати повноцінні 4 ГБ оперативної пам’яті, оскільки MS вирішила не включати функції PAE на ньому. Ядро, яке тісно пов'язане, Windows 2003 Server, підтримує PAE. Однак навіть там "Стандартне видання" підтримуватиме до 4 Гб (але працює навколо отвору для пам'яті BIOS), тоді як більш дорогі видання дозволять забезпечити до 64 ГБ оперативної пам'яті. Те ж саме стосується 32-бітної Vista .

Однак не у всіх випадках це обмеження, накладене Windows. Якби це було, завантаження ядра Linux з підтримкою PAE все одно дозволило б використовувати повні 4 ГБ (або більше). Не так, деякі виробники обладнання вирішили накласти це обмеження на рівні BIOS, хоча процесор і чіпсет могли б обробляти PAE.


Лише бічне зауваження: жоден із поточних 64-бітових процесорів на базі x86 навіть фізично не може вирішити весь діапазон 64-бітового адресного простору (для ознайомлення див. Це питання та відповіді).


Хм, чому мені складається враження, що Лінус справді ненавидить HIGHMEM.SYS і PAE? : P
Каран

2
Я розумію, що PAE буде неприємністю для будь-якого коду, для якого потрібно більше пари гігів робочого набору, і для коду на рівні системи, якому потрібно керувати декількома завданнями по 2 гіга або близько кожного, але якщо тільки для однієї програми потрібно більше 2 концерти, я б очікував, що PAE буде прозорим. Крім того, я думаю, що PAE також буде кращим, ніж глобальне використання 64-бітних покажчиків у випадках, коли потрібні 3 гіга оперативної пам’яті загального призначення плюс великий дисковий кеш або накопичувач темп-накопичувача.
supercat

Коментар Лінуса дивний. Не існує зв’язку між тим, як працює himem.sys і тим, як працює PAE. Дуже забавно бачити, як люди сперечаються за x64 і проти PAE-адреси ... коли довгий режим x64 просто приймає схему PAE і додає ще один рівень таблиці сторінок!
Джеймі Ханрахан

@JamieHanrahan: ... принаймні два на новіших системах (завдяки віртуалізації), що відкриває деякі захоплюючі можливості. Його порівняння (Лінуса) не зовсім правильні, але якщо це іноземна концепція, метафори можуть допомогти :) ... Я думаю, саме тому він обрав це, щоб зробити свою думку.
0xC0000022L

2

8-бітні процесори зазвичай мали 16-бітну шину адреси. (Motorola мала єдину шину адрес, оперативна пам’ять та периферійний введення / виведення поділяли один і той же адресний простір; Intel вирішила розділити два. У випадку Intel обмеження адрес IO 8088 і 8086 переносили обмеження, переведені з 8080 & 8085 ЦП.)

Intel 8088 та 8086 мали 20-бітну шину адреси пам'яті (1 МБ), а Motorola 68000 - 24-бітну шину адреси (16 Мб). IIRC, [80] 286 перейшов на 24-бітну адресну шину. Обидва пізніше розширилися до 32-бітної шини адреси з [80] 386 та 68020 відповідно.) З мікросхемами Pentium адресна шина розширилася до 64-біт. (Я думаю, що мікросхеми PowerPC від компанії Motorola / IBM також пішли на 64-бітну адресну шину.)

Пам'ять, наявна внизу та до максимальної кількості, до якої безпосередньо можна було отримати доступ до центрального процесора, була обмежена лише підтримуючими апаратними чіпами (чіпсетом) та ОС. Білл Гейтс був відомий у минулому тим, що заявив, що нікому не потрібно більше 640 КБ оперативної пам’яті, таким чином DOS ніколи не розвивався для прямого доступу до більшої ОЗУ. Завдяки HiMem.sys та EMM386 DOS було розширено для доступу до більшої "верхньої" пам'яті, EMM386 використовувався для прямого доступу до всієї доступної оперативної пам'яті. HiMem.sys мав меншу гнучкість і в основному міг використовувати додаткову оперативну пам’ять для зберігання.

Пам'ять, що перевищує цей ліміт, вимагала MMU (Unit Management Memory), щоб розбити пам'ять на сегменти і відобразити її в адресному просторі пам'яті CPU. Так CoCo 3, Commodore 128 та інші 8-бітні комп’ютери могли отримати доступ до понад 64 Кб оперативної пам’яті.

Більш вигідним зараз є використання віртуальної пам'яті для розширення минулих меж фізичної пам'яті, хоча і з обмеженнями, накладеними ОС.


1

Тому що для цього немає жодної практичної причини. Фізичні розширення адрес дозволяють практично однакову функціональність, і їх використання все ще дуже обмежене серед користувачів. У Windows 3.1 дня були обмеження, яких сьогодні просто немає.


1
Це дійсно недостатньо інформації для резервного копіювання ваших заяв. Windows 3.1 - це 16-бітна операційна система. Потрібно пам’ятати, що в 1992 році 2 МБ пам’яті було понад 300 доларів.
Рамхаунд

Ви коментуєте 22 лютого, а пояснення Скотта Чемберліна в значній мірі висвітлюють те, на чому я їхав. Вони не залишають описів того, чому розширювана сегментована сторінки використовувалася в DOS / Win16, але не в пізніших Windows. Я не включав це, оскільки це не сприяло б прямому відповіді на питання ОП.
OCDtech

На мій погляд, відповіді повинні стояти окремо. Ваш коментар додає достатньо інформації, щоб вирішити мої проблеми з вашою відповіддю.
Рамхаунд

1
@OCDtech: сегментована модель 8086 дозволила б об'єктно-орієнтованій мові використовувати 2-байтні посилання на об'єкти для ідентифікації об'єктів, вирівняних за 16-байтовими межами, але мови були недостатньо обладнані для ефективного використання сегментів. Модель 80286 накладає жахливо більший накладні витрати на такі програми, і спосіб її поширення на 80386 зробить схему сегмента на об'єкт абсолютно марною.
supercat

0

Теоретичні межі пам'яті в 16, 32 та 64 бітових машинах такі:

Основним недоліком тут є уявлення про те, що "бітова ширина" процесора, яка зазвичай є розміром регістрів загального призначення машини, обов'язково така сама, як і ширина адрес ОЗУ.

У x86 із включеним підкачкою, але без PAE адреси, які використовує програма та код ОС, Intel називають "лінійними адресами" - ми зазвичай називаємо їх "віртуальними адресами". Вони шириною 32 біти. Це дозволяє віртуальний адресний простір 4 Гб.

Але це більш-менш збіг, лише артефакт формату записів у таблиці сторінки, що розмір фізичної адреси (ОЗП) також становить 32 біти.

З PAE останній становить 36 біт (спочатку ... ширший у пізніших реалізаціях). Отже, лише тому, що це, наприклад, "32-бітна машина", не означає, що адреси фізичної пам'яті обмежені 32 бітами.

Промисловість має довгу історію машин, «ширина біту» яких не відповідала їх максимальному розміру фізичної адреси. Наприклад, архітектура VAX визначає 32-бітну машину, а віртуальні адреси (це адреси, які використовуються кодом після включення перекладу адрес) дійсно мають ширину 32 біти ..., але фізичні адреси VAX мають лише 30 біт ширини - і половина фізичного адресного простору присвячена регістрам пристроїв вводу / виводу, тому максимальна оперативна пам'ять становила всього 512 МБ.

Навіть без апаратного перекладу адрес не обов’язково виходить, що "бітова ширина" машини визначає максимальну адресу оперативної пам'яті. Приклад: Серія CDC "Верхній 3000" була 36-розрядною машиною. Як ви думаєте, вони могли б вирішити 64 Гб оперативної пам’яті? Не важко! Ці машини вийшли в середині 60-х! Чорт, у ті дні ми навіть не могли мати 64 Гб дискового простору . (Серія CDC 6000 була 60-розрядною машиною. Потрібно продовжувати?)


І не забувайте про системи, які не використовують 8-біт на оперативну пам’ять. (EG: 16/16 = 128K макс., 32/32 = 16G Макс.,
32/64
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.