Чому системи x86-64 мають лише 48-бітний віртуальний адресний простір?


97

У книзі я прочитав таке:

32-розрядні процесори мають 2 ^ 32 можливі адреси, тоді як поточні 64-розрядні процесори мають 48-розрядний адресний простір

Я сподівався, що якщо це 64-розрядний процесор, адресний простір також повинен бути 2 ^ 64.

Тож мені було цікаво, в чому причина цього обмеження?


11
У книзі, мабуть, йшлося конкретно про поточну реалізацію архітектури AMD64 (x86-64). Використовуються лише 48 біт нижчого порядку. Однак це не апаратне обмеження - доступні всі 64 біти.
Коді Грей

7
Завжди хороша ідея ідентифікувати книгу.
Henk Holterman

1
Я здогадуюсь, що рядки фізичної адреси не є безкоштовними (вам потрібно щонайменше 16 додаткових контактів процесора). І я ще не знаю жодного обладнання, яке може заповнити 48-бітний простір фізичними чіпами оперативної пам'яті на тому самому процесорі. Коли це стане можливим, я впевнений, AMD додасть відсутні 16 штифтів :)
Torp

7
навіть, The 32-bit processors have 2^32 possible addressesце не обов'язково вірно, може існувати 32-бітний процесор з лише 24 "контактами" для адресації пам'яті. Наприклад, 68EC020 (дешевша версія 68020) - це 32-бітний процесор, але з 24 бітами для адресації пам'яті.
ShinTakezou

21
Існує цілком реальна проблема з 64-розрядною фізичною адресацією, розмір сторінки віртуальної пам'яті занадто малий. Що створює величезні каталоги сторінок і надзвичайно дорогий змив кешу TLB на кожному перемикачі контексту. Перехід від 4 КБ до 4 Мб сторінок є варіантом, але дуже несумісним із поточними операційними системами.
Ганс Пассант,

Відповіді:


134

Бо це все, що потрібно. 48 біт дають вам адресний простір 256 терабайт. Це багато. Незабаром ви не побачите системи, яка потребує більше, ніж це.

Тож виробники процесорів скористались ярликом. Вони використовують набір команд, що дозволяє отримати повний 64-бітний адресний простір, але поточні процесори просто використовують лише нижчі 48 бітів. Альтернативою було витратити транзистори на обробку більшого адресного простору, який не потрібен був довгі роки.

Отож, коли ми наближаємось до 48-бітової межі, це просто питання випуску процесорів, які обробляють повний адресний простір, але це не вимагатиме змін у наборі інструкцій і не порушить сумісності.


118
640кб достатньо для всіх.

7
Ви все ще використовуєте систему 8088, bdares?
Джо,

23
@bdares: Погана аналогія. Набір інструкцій арки 8088/8086 має вбудований ліміт 640k. Тільки виготовивши новий ISA (386), вдалося пробити бар’єр. x86_64, з іншого боку, підтримує всі 64 біти в ISA. Це просто обладнання сучасного покоління, яке не може використовувати їх усіх ...
R .. GitHub СТОП ДОПОМОГАЙ ЛЕД

16
@R. Насправді обмеження процесора становило один мегабайт. IBM PC призначив частину цього розділу для периферійних пристроїв, що відображаються на пам'ять, BIOS і т. Д. Деякі інші конструкції 8088/8086 (Zenith Z100, якщо пам'ять обслуговує) призначені менше для периферійних пристроїв та подібних, і відповідно більше для прикладних програм.
Джеррі Коффін,

25
lwn.net/SubscriberLink/655437/9a48cd3e7a8cbe8a <- через три роки після цієї відповіді ми вже досягаємо цих обмежень :) Машина HP матиме 320 ТБ пам'яті, і вони не можуть надати її як плоский адресний простір через 48 -бітове обмеження адресації.
агам

18

Будь-яка відповідь, що стосується розміру шини та фізичної пам’яті, є дещо помилковою, оскільки питання OP стосувалося віртуального адресного простору, а не фізичного адресного простору . Наприклад, нібито аналогічним обмеженням для деяких 386 було обмеження фізичної пам'яті, яку вони могли використовувати, а не віртуального адресного простору, який завжди складав 32 бити. В принципі, ви можете використовувати цілі 64 біти віртуального адресного простору, навіть маючи лише кілька МБ фізичної пам'яті; звичайно, ви можете зробити це, помінявшись місцями, або для спеціалізованих завдань, де ви хочете зіставити одну і ту ж сторінку з більшістю адрес (наприклад, певні операції з розрідженими даними).

Я думаю, що справжня відповідь полягає в тому, що AMD просто коштувала дешево і сподівалася, що зараз ніхто не потурбується, але я не маю посилань на цитування.


14
"Бути дешевим", мабуть, ви маєте на увазі не додавати штифти, які ніколи не використовуватимуться, не займати місця на мікросхемах для транзисторів, які не будуть використовуватися, і використовувати звільнений простір для швидшого здійснення існуючих інструкцій? Якщо це дешево, я тут!
Олоф Форшелл

80386 дозволяє 2 * 4096 селекторів, кожен з яких містить до 4 ГБ пам'яті (загальна кількість 32 ТБ). 80286 дозволив 2 * 4096 селекторів, кожен з яких містив до 64 КБ (1 ГБ).
Олоф Форшелл

Нелінійні сегментовані хаки не враховуються як адресний простір у моїй книзі. Портативне програмне забезпечення не може ними користуватися.
R .. GitHub СТОП ДОПОМОГАЙ ЛЕД

@R .. - Я думав, що визначення портативного програмного забезпечення полягає в тому, що воно може . :-) Наприклад, C ++ забороняє порівнювати покажчики на різні масиви, щоб вони могли знаходитися в окремих сегментах по 4 Гб.
Бо Перссон,

Якщо ваша компіляція насправді генерує величезні вказівники та завантажує сегментний регістр для кожного призначення пам'яті, тоді так. Але насправді це жахливо повільно, і замість цього всі використовували маленькі моделі пам’яті та __far(або ще гірше, FAR/ far!) Покажчики ...
R .. GitHub СТОП ДОПОМОГАЙ ЛЕД

10

Прочитайте розділ обмежень статті Вікіпедії :

ПК не може містити 4 петабайти пам'яті (через розмір поточних мікросхем пам'яті, якщо нічого іншого), але AMD передбачала великі сервери, кластери спільної пам'яті та інші види використання фізичного адресного простору, які можуть наблизитися до цього в осяжному майбутньому, і 52 бітова фізична адреса забезпечує широкий простір для розширення, не несучи витрат на реалізацію 64-розрядних фізичних адрес

Тобто на даний момент немає сенсу реалізовувати повну 64-бітову адресацію, оскільки ми не можемо створити систему, яка могла б повністю використовувати такий адресний простір - тому ми вибираємо щось практичне для сьогоднішніх (і завтрашніх) систем.


Звідки беруться 4 у 4 петабайтах? Якщо ми говоримо про 64 адресних рядки, то в підсумку ми повинні отримати квадрат адресного простору, який став можливим завдяки 32 адресним рядкам, що становить 4 гігабайти. Квадрат, і ми повинні мати 16, а не 4 петабайти. Я щось пропускаю?
Olof Forshell

1
Це походить від поточного фізичного обмеження (52 біти) - суть полягає в тому, що ми не можемо помістити в ПК достатньо оперативної пам'яті для підтримки цього обмеженого діапазону, не кажучи вже про те, що потрібно для повного 64-бітного адресного простору.
Damien_The_Unbeliever

9

Внутрішній власний регістр / ширина операції не потрібно відображати у зовнішній ширині шини адреси.

Скажімо, у вас 64-розрядний процесор, якому потрібно лише 1 мегабайт оперативної пам'яті. Все, що потрібно, - 20-бітна шина адреси. Навіщо турбуватися про вартість та апаратну складність усіх зайвих штифтів, якими ви не будете користуватися?

Motorola 68000 була такою; 32-бітний внутрішньо, але з 23-бітовою адресною шиною (і 16-бітовою шиною даних). Процесор міг отримати доступ до 16 мегабайт оперативної пам'яті, а для завантаження власного типу даних (32 біта) знадобилося два звернення до пам'яті (кожна з 16 біт даних).


1
але 68000 розглядається як "16/32 бітний" процесор, а не "повний" 32 бітний процесор, тому можна сказати, що він все ще має ногу в 16-бітному минулому; Як приклад я вибрав 68020, оскільки його недорога версія 68EC020 має 24 біти лише для адрес, хоча 68020 - це "повний" 32-бітний процесор ... +1, який вважав цю чудову сімейство процесорів!
ShinTakezou

@ShinTakezou: чесно кажучи, чи був 80386SX 16-розрядним процесором (оскільки він мав адресний простір, як 80286), чи 32-розрядним (оскільки він мав внутрішню архітектуру 80386DX)? Можна сказати так само, як ти, але інший (цей) каже, що "внутрішнє - це те, що має значення" - і ти можеш цитувати мене з цього приводу.
Olof Forshell

@Olof Я думаю, що в контексті "пам'яті" (яка є зовнішнім світом) має значення саме зовнішнє, тож 68000 - це 16-бітний процесор (для читання 32-бітних даних потрібні 2 "кроки"): D
ShinTakezou

@ShinTakezou: контекст пам'яті, навіть кеш-пам’яті, завжди є зовнішнім для самого процесора, хоча вони надзвичайно тісно пов’язані в сучасних процесорах. 8088 був внутрішньо рівним 8086, хоча мав вісім ліній шини даних до шістнадцяти 8086. Я не бачу , що ви , по- видимому бачити , як очевидно, що 8088 слід класифікувати у тій самій групі, що і Z80, 8080, 8085 і т.д. Питання про ширину шини даних здається тривіальним в цьому контексті
Олоф Forshell

Я взагалі не фахівець у такій справі, тому для мене немає нічого очевидного. Я хотів просто помітити необхідність більш чіткого зрізання з минулим, де можна подумати, що 68000 все ще є процесором "старого часу", тому що може здатися "природним", що його адресний простір обмежений менше 32 біт; тоді як 68020 може 32 біт, так що існування 68EC020 з його обмеженням дає зрозуміти, що це вибір не через "межу цього ( або цей) час ", але з іншого розгляду (наприклад, зробити його дешевшим, якщо немає реальних переваг у наявності 64 штифтів), що є більш-менш аргументом цієї відповіді.
ShinTakezou

7

Існує більш серйозна причина, ніж просто збереження транзисторів у шляху адреси процесора: якщо ви збільшуєте розмір адресного простору, вам потрібно збільшити розмір сторінки, збільшити розмір таблиць сторінок або мати більш глибоку структуру таблиці сторінок (що більше рівнів таблиць перекладу). Усі ці речі збільшують вартість пропуску TLB, що шкодить продуктивності.


1
Intel пропонує п'ятирівневу схему пейджингового розширення з поточних 48 бітів до 57 бітів. (Ті самі 9 біт на рівень / 4 тис. Сторінок, що й поточні таблиці сторінок x86-64). Використання 10 або 11 біт на рівень вимагало б зміни обладнання для прогулянки сторінок, тому це може бути не оптимальним дизайном для величезної пам'яті, але це розумне розширення для дворежимного центрального процесора, який також повинен підтримувати максимальну продуктивність для 4- таблиці рівня в поточному форматі.
Пітер Кордес,

Звичайно, у 2M або 1G величезних сторінок це лише 4 або 3 рівні таблиць сторінок від верхнього рівня до запису таблиці величезних сторінок замість вказівника каталогу сторінок.
Пітер Кордес,

6

З моєї точки зору, це результат розміру сторінки. Кожна сторінка містить максимум 4096/8 = 512 записів таблиці сторінок. І 2 ^ 9 = 512. Отже 9 * 4 + 12 = 48.


4

Щоб відповісти на вихідне запитання: Не потрібно було додавати більше 48 біт PA.

Серверам потрібен максимальний обсяг пам’яті, тому спробуємо копати глибше.

1) Найбільшою (загальновживаною) конфігурацією сервера є система 8 Socket. Система 8S - це не що інше, як 8-серверний процесор, з'єднаний високошвидкісним когерентним з'єднанням (або просто високошвидкісною "шиною"), щоб утворити єдиний вузол. Є більші кластери, але їх небагато, ми говоримо про загальновживані конфігурації. Зверніть увагу, що в реальному звичаї система 2 Socket є одним із найбільш часто використовуваних серверів, а 8S, як правило, вважається дуже висококласним.

2) Основними типами пам’яті, що використовується серверами, є байтова адресаційна звичайна пам’ять DRAM (наприклад, пам’ять DDR3 / DDR4), відображена пам’ять IO - MMIO (така як пам’ять, що використовується додатковою картою), а також конфігураційний простір, який використовується для налаштування пристроїв, які присутні в системі. Перший тип пам'яті - це та, яка, як правило, найбільша (і, отже, потребує найбільшої кількості бітів адреси). Деякі висококласні сервери також використовують велику кількість MMIO, залежно від фактичної конфігурації системи.

3) Припустимо, кожен центральний процесор може містити 16 модулів DDR4 DIMM в кожному слоті. Максимальний розмір DDR4 DIMM 256 ГБ. (Залежно від версії сервера, ця кількість можливих модулів DIMM на сокет фактично менше 16 модулів DIMM, але продовжуйте читати заради прикладу).

Отже, кожен сокет теоретично може мати 16 * 256 ГБ = 4096 ГБ = 4 ТБ. Для нашої прикладної системи 8S розмір DRAM може становити максимум 4 * 8 = 32 ТБ. Це означає, що максимальна кількість бітів, необхідна для вирішення цього простору DRAM, становить 45 (= log2 32TB / log2 2).

Ми не будемо вдаватися в подробиці інших типів пам'яті (MMIO, MMCFG тощо), але справа тут у тому, що найбільш "вимогливий" тип пам'яті для 8-сокетної системи з найбільшими типами модулів DDR4 DIMM, доступних сьогодні (256 ГБ) DIMM-модулі) використовують лише 45 біт.

Для ОС, яка підтримує 48 біт (наприклад, WS16), залишається (48-45 =) 3 біти. Це означає, що якщо ми використовували нижчі 45 біт виключно для 32 ТБ DRAM, ми все ще маємо 2 ^ 3 рази адресируемой пам'яті, яку можна використовувати для MMIO / MMCFG загалом 256 ТБ адресного простору.

Отже, підсумовуючи: 1) 48 біт фізичної адреси - це безліч бітів для підтримки найбільших систем сучасності, які "повністю завантажені" великою кількістю DDR4, а також великою кількістю інших пристроїв вводу-виводу, які вимагають місця MMIO. 256 ТБ, якщо бути точним.

Зверніть увагу, що цей адресний простір на 256 ТБ (= 48 біт фізичної адреси) НЕ включає жодних дискових накопичувачів, таких як диски SATA, оскільки вони НЕ є частиною адресної карти, вони містять лише пам'ять, яка може бути адресована байтом і піддається ОС.

2) Апаратне забезпечення центрального процесора може вибрати 46, 48 або> 48 бітів, залежно від генерації сервера. Але ще одним важливим фактором є те, скільки розрядів розпізнає ОС. Сьогодні WS16 підтримує 48-бітові фізичні адреси (= 256 ТБ).

Що це означає для користувача, навіть якщо у нього є великий, надсучасний серверний процесор, який може підтримувати> 48 біт адресації, якщо ви запускаєте ОС, яка підтримує лише 48 біт PA, тоді ви можете скористатися лише 256 ТБ .

3) Загалом, є два основних фактори, які дозволяють скористатися більшою кількістю адресних бітів (= більший об’єм пам’яті).

а) Скільки біт підтримує ваш процесор HW? (Це можна визначити за інструкцією CPUID в процесорах Intel).

б) Яку версію ОС ви використовуєте та скільки біт PA вона розпізнає / підтримує.

Мінімальне значення (a, b) в кінцевому рахунку визначатиме кількість адресного простору, яким може скористатися ваша система.

Я написав цю відповідь, не детально розглядаючи інші відповіді. Крім того, я не докладно вникав у нюанси MMIO, MMCFG та всю конструкцію адресної карти. Але я сподіваюся, це допоможе.

Дякую, Anand K Enamandram, архітектор серверної платформи Intel Corporation


Це питання ставить питання про розмір 48-бітного віртуального адресного простору (вимагаючи, щоб віртуальні адреси були канонічними). Вам потрібно більше віртуальних бітів, ніж фізичних, тому ядро ​​старшої половини може зіставити всю фізичну пам'ять в єдиний адресний простір (власний або користувацький). Як ви кажете, HW має реалізувати лише стільки бітів PA, скільки можуть використовувати контролери DRAM + MMIO, і може використовувати будь-яке число до 52-бітового обмеження у форматі таблиці сторінок x86-64. ( Чому у 64-бітної віртуальної адреси коротше 4 біти (довжина 48 бітів) порівняно з фізичною адресою (довжина 52 біта)? )
Пітер Кордес,

1
Формат таблиці сторінок з 4 рівнями також накладає обмеження на 48 біт VA, поки HW + SW не підтримують таблиці сторінок PML5 для 57-бітних VA. У будь-якому випадку, це корисна відповідь, але, схоже, вона розміщена під неправильним запитанням. Я не впевнений, що для цього є краще місце, тому, мабуть, ми можемо залишити це тут, сподіваємось, з редагуванням, щоб додати заголовок, щоб сказати щось про PA проти VA.
Пітер Кордес,

2

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

Якщо сказати, що 32-розрядний або 64-розрядний процесор не означає, що він повинен мати 32-розрядну адресну шину або 64-розрядну адресну шину відповідно! ... Я повторюю це НЕ !!

32-розрядний процесор означає, що він має 32-розрядний ALU (арифметичний та логічний блок) ... це означає, що він може працювати з 32-розрядним двійковим операндом (або просто вимовляючи двійкове число, що має 32 розряди), і подібним чином 64-розрядний процесор може працювати з 64-розрядним двійковим процесором операнд. Отже, погодні 32-розрядний або 64-розрядний процесор НЕ означає, що можна встановити максимальний обсяг пам'яті. Вони просто показують, наскільки великий операнд може бути ... (для аналогії ви можете подумати, що 10-значний калькулятор може обчислювати результати до 10 цифр ... він не може дати нам 11 цифр або будь-які інші більші результати ... хоча це в десяткових кодах, але я кажу цю аналогію для простоти) ... але те, що ви говорите, - це адресний простір, який є максимальним безпосередньо інтерфейсним обсягом пам'яті (ОЗУ). ОЗУ s Максимально можливий розмір визначається розміром шини адреси, і це не розмір шини даних або навіть ALU, на якій визначається розмір процесора (32/64 біт). Так, якщо процесор має 32-бітну "Адресну шину", тоді він може адресувати 2 ^ 32 байта = 4 ГБ оперативної пам'яті (або для 64-бітової версії це буде 2 ^ 64) ... але якщо сказати, що 32-бітний або 64-бітний процесор має нічого не має значення для цього адресного простору (адресний простір = наскільки він може отримати доступ до пам'яті або максимальний розмір оперативної пам'яті), і це залежить лише від розміру його ALU. Звичайно, шина даних та адресна шина можуть бути однакового розміру, і тоді може здатися, що 32-бітний процесор означає, що він матиме доступ до 2 ^ 32 байт або 4 ГБ пам'яті ... але це лише збіг обставин, і він не буде однаковим для усіх.... наприклад, intel 8086 - це 16-розрядний процесор (оскільки він має 16-розрядний ALU), тому, як ви говорите, він повинен був отримати доступ до 2 ^ 16 байт = 64 КБ пам'яті, але це неправда. Він може отримати доступ до 1 Мб пам’яті за наявність 20-бітної адресної шини .... Якщо у вас є якісь сумніви, ви можете загуглити в Google :)

Думаю, я чітко висловив свою думку. Тепер, переходячи до вашого запитання ... оскільки 64-бітний процесор не означає, що він повинен мати 64-бітну адресну шину, тому немає нічого поганого в тому, що в 64-бітному процесорі є 48-бітна шина адрес. ... вони зменшили адресний простір меншим, щоб зробити проектування та виготовлення дешевими .... оскільки ніхто не збирається використовувати таку велику пам’ять (2 ^ 64 байта) ... де 2 ^ 48 байт сьогодні більш ніж достатньо.


Думаю, ви чітко висловили свою думку, але я не розумію однієї речі, хоча в тому, що ви сказали про 16-бітовий процесор 8086: як може 16-бітний процесор обробляти 20-бітову адресу? Чи впорається це з двохетапною операцією? Навіть якщо шина адреси становить 20 біт, як тільки вона потрапляє до центрального процесора, ширина реєстру, очевидно, може зайняти лише 16 бітів ... Як вони це роблять?
programmersn

2
Хм ... 2 кроки. Регістр сегментів містить лише верхні 16 бітів. Потім його множать на 10Н, щоб зробити 20 біт, а потім додають зміщення.
hafiz031

1

Це неправда, що використовуються лише 48-бітові 64-бітні VA низького рівня, принаймні з Intel 64. Верхні 16 бітів використовуються, свого роду, такого роду.

Розділ 3.3.7.1 Канонічна адресація в Посібнику розробника програмного забезпечення для архітектур Intel® 64 та IA-32 говорить:

канонічна адреса повинна мати біти від 63 до 48, встановлені на нулі або одиниці (залежно від того, біт 47 дорівнює нулю чи одиниці)

Отже, біти від 47 до 63 утворюють супербіт, або всі 1, або всі 0. Якщо адреса не в канонічній формі, реалізація повинна вийти з ладу.

На AArch64 це інакше. Згідно з оглядом набору інструкцій ARMv8 , це 49-розрядна VA.

Система перекладу пам'яті AArch64 підтримує 49-бітну віртуальну адресу (48 біт на таблицю перекладу). Віртуальні адреси розширюються знаком з 49 біт і зберігаються в 64-бітному покажчику. За бажанням, під контролем системного реєстру, найбільш значущі 8 бітів 64-розрядного вказівника можуть містити "тег", який буде проігнорований при використанні як адреси завантаження / зберігання або цілі непрямої гілки


1
Значущими є лише нижні 48, але апаратне забезпечення перевіряє, чи правильно воно розширено до 64 біт. IDK, чому вони не вказали нульове розширення; можливо, вони хотіли зробити зручнішим перевірку на високу або низьку половину адреси (просто перевіривши знаковий біт). Або, можливо, щоб уникнути особливої ​​межі 2 ^ 48, і тому адреси вгорі можуть зручно вміститися в 32-розрядні константи, розширені знаком. Я думаю, що останнє є більш вірогідним.
Пітер Кордес,

У будь-якому випадку, поточна перевірка HW на канонічність заважає програмному забезпеченню використовувати ігноровані біти для тегованих покажчиків, які зламаються на майбутніх HW, тому це частина механізму, який дозволяє розширити майбутнє обладнання, якщо / коли це буде потрібно. (Що може бути швидше, ніж вони очікували, завдяки енергонезалежній пам'яті, яка підключається безпосередньо до фізичного та віртуального адресного простору.)
Пітер Кордес,

procfs в Linux на моєму Core i5 каже, що він перетворюється на 7ffd5ea41000-7ffd5ea62000. Цей діапазон адрес має сенс відповідно до вищезазначеного «канонічного» правила. Біти 48-63 дорівнюють 0, що робить його правильною канонічною адресою. Щось дивним є деякі адреси у джерелі Linux. У include / asm / pgtable_64_types написано #define __VMALLOC_BASE _AC (0xff92000000000000, UL). Це НЕ канонічна адреса. Така адреса починалася б з 0xffff8. Не знаю чому.
Olsonist,

Так, IIRC Linux використовує нижчу половину канонічного діапазону для простору користувача і (переважно) використовує верхню половину для зіставлення лише ядра. Але частина пам’яті ядра експортується в простір користувача, як [vsyscall]сторінка. (Це може експортувати такі речі, як поточний PID, так що getpid()це просто користувацький простір. Також gettimeofday()можна просто використовувати rdtsc в просторі користувача + масштабні коефіцієнти, експортовані ядром. Хоча деякі з них я думаю [vdso], що знаходиться вгорі на нижня половина.)
Пітер Кордес,

IDK що __VMALLOC_BASEробить. Імовірно, він не використовується безпосередньо.
Пітер Кордес,

0

Процесор вважається "N-бітами" головним чином за розміром його шини даних та за великою частиною його сутностей (внутрішня архітектура) : регістри, акумулятори, арифметико-логічний блок (ALU), набір інструкцій тощо. Наприклад: Старий добрий процесор Motorola 6800 (або Intel 8050) - це 8-бітний процесор. Він має 8-бітову шину даних, 8-бітову внутрішню архітектуру та 16-бітову адресну шину.


  • Хоча N-бітовий процесор може мати і інші, крім N-розмірних об'єктів. Наприклад, впровадження в 6809 над 6800 (обидва вони - 8-бітний процесор з 8-бітовою шиною даних). Серед значних удосконалень, представлених в 6809, було використання двох 8-розрядних акумуляторів (A і B, які можна було об'єднати в єдиний 16-розрядний регістр, D), двох 16-розрядних індексних регістрів (X, Y) та двох 16-розрядні покажчики стека.

На це вже є відповідь, наприклад Motorola 68000/68020. Це питання насправді стосується x86-64, а не старих 8/16-розрядних процесорів. У випадку з x86-64 одним із головних факторів є те, що для ширших віртуальних адрес потрібна буде глибша таблиця сторінок, і цього фактора не існувало для старих чіпів, про які ви говорите.
Пітер Кордес,

ширина шини даних не повинна відповідати регістру або ширині ALU. Наприклад, P5 Pentium має 64-бітну шину даних (вирівняні 64-бітні завантаження / сховища гарантовано є атомними), але регістри / ALU мають лише 32 біти (за винятком інтегрованого FPU, а в пізніших Pentium MMX SIMD ALUs.)
Пітер Кордес,

OP пише: "Моє сподівання полягало в тому, що якщо це 64-розрядний процесор, адресний простір також повинен бути 2 ^ 64". ........ Ви пишете: "Це питання насправді стосується x86-64, а не старих 8/16-розрядних процесорів". ........ Я думаю, ви пропустили суть питання ОП. Питання OP - результат неправильного припущення, що 64-бітний процесор повинен мати 64-бітову адресну шину. Про АЛУ я писав значну частину його сутностей; Не всі.
Аміт Г.

Перестаньте спамувати мене, розмістивши цей коментар. Так, звичайно, OP є неправильним з тієї причини, яку ви описуєте, але я вказував, що ваша відповідь схожа на те, що вона робить подібну помилку. Ви говорите " і, отже, велика частина його сутностей: реєстри та акумулятори, арифметико-логічний блок (ALU) ... ", що звучить так, ніби ви говорите, що ці речі відповідають ширині шини даних. Фраза "велика частина" означає, що ви говорите, які частини, а не те, що це іноді справедливо для цих частин.
Пітер Кордес,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.