Разрядность шины адреса процессора intel core i5

О разрядности процессоров

Целью данной статьи является попытка посеять сомнение в голове читателя, уверенного, что он знает о разрядности всё или почти всё. Но сомнение должно быть конструктивным, дабы сподвигнуть на собственное исследование и улучшить понимание.

Термин «разрядность» часто используют при описании вычислительных устройств и систем, понимая под этим число бит, одновременно хранимых, обрабатываемых или передаваемых в другое устройство. Но именно применительно к центральным процессорам (ЦП), как к наиболее сложным представителям вычислительного железа, не делимым на отдельные детали (до тех пор, пока кто-то не придумал, как продать отдельно кэш или умножитель внутри чипа), понятие разрядности оказывается весьма расплывчатым. Продемонстрировать это поможет умозрительный пример.

Представьте себе, что вокруг благодатные 80-е, в мире (всё ещё) десятки производителей ЦП, и вы работаете в одном из них над очередным поколением. Никаких 256-битных SSE8, встроенных GPU и 5-канальных контроллёров памяти на свете пока нет, но у вас уже есть готовый 16-битный процессор (точнее, «16-битный» пишется в технической документации), в котором 16 бит везде и во всём — от всех внешних шин до архитектурного размера обрабатываемых данных. Реальным примером такого ЦП могут быть первые однокорпусные (правда, не однокристальные) ЦП для архитектуры DEC PDP-11. И вот приходит задание руководства — разработать новое, обратно совместимое поколение этого же ЦП, которое будет 32-битным — не уточняя, что понимается под последним. Именно это понимание и предстоит прояснить в первую очередь. Итак, наш главный вопрос: что именно надо удвоить по разрядности в нашем пока насквозь 16-битном ЦП, чтобы получившийся процессор мог называться 32-битным? Чтобы решать задачу было легче, применим два подхода: систематизируем определения и посмотрим на примеры.Систематизируем

Первое, что приходит в голову — разрядность чего именно считать? Обратимся к определению любой информационной системы: её три основных функции — это обработка, хранение и ввод-вывод данных, за которые отвечают, соответственно, процессор(ы), память и периферия. Учитывая, что сложная иерархически самоподобная система состоит из многих компонент, можно утверждать, что такое разделение функций сохраняется и на компонентном уровне. Например, тот же процессор в основном обрабатывает данные, но он также обязан их хранить (для чего у него есть относительно небольшая память) и обмениваться с другими компонентами (для этого есть разные шины и их контроллёры). Поэтому будем функционально разделять разрядности обработки, хранения и обмена информации.

Рискну предположить, что все производители любого программируемого «железа», особенно процессоров, на 90% стараются не для конечных пользователей, а для программистов. Следовательно, с точки зрения производителей процессор должен выполнять нужные команды нужным образом. С другой стороны, детали структуры кристалла (топологические, электрические и физические параметры отдельных транзисторов, вентилей, логических элементов и блоков) могут быть скрыты не только от пользователя, но и от программиста. Выходит, что разрядность надо отличать и по реализации — физическую и архитектурную.

Следует добавить, что программисты тоже бывают разные: большинство пишут прикладные программы на языках высокого уровня с помощью компиляторов (что делает код до некоторой степени платформонезависимым), некоторые пишут драйверы и компоненты ОС (что заставляет более внимательно относиться к учёту реальных возможностей аппаратной части), есть творцы на ассемблере (явно требующем знания целевого процессора), а кто-то пишет сами компиляторы и ассемблеры (аналогично). Поэтому под программистами далее будем понимать именно тех, для кого детали аппаратной реализации важны если не для написания программы вообще, то хотя бы для её оптимизации по скорости — «архитектурная» разрядность чего-либо будет относиться именно к программированию на родном машинном языке процессора или более удобном ассемблере, не залезая при этом в нутро ЦП (это уже вопросы микроархитектуры, которую мы для большего различия и назвали физической реализацией). Описанные нюансы всё равно влияют на всех программистов, т.к. языки высокого уровня почти всегда переводятся компиляторами в машинный код, а компиляторы тоже должен кто-то написать. Исключения в виде интерпретируемых языков тоже не стоят в стороне — сами интерпретаторы тоже создаются с помощью компиляторов.

Осталось рассмотреть, разрядность какой именно информации нам интересна. Что вообще потребляет и генерирует ЦП в информационном смысле? Команды, данные, адреса и сигнально-управляющие коды. О последних речь не идёт — их разрядность жёстко зафиксирована в конкретной аппаратной реализации и в большинстве случаев программно не управляема. Чуть трудней с командами — в семействе архитектур RISC, например, разрядность любого обращения к памяти должна быть равна физической разрядности шины данных процессора, в т.ч. и при считывании кода (кроме некоторых послаблений в современных ARM и PowerPC). Это хорошо для ЦП — нет проблем с невыровненным доступом, все команды имеют одинаковую, либо переменную, но просто вычисляемую длину. Зато плохо для программиста — RISC это усечённый набор команд, которые ещё и занимают больше места, чем при более компактном кодировании (для того же алгоритма нужно больше команд, но и для того же числа команд надо больше байтов). Поэтому именно CISC-парадигма завоевала наибольший подход с её разнообразием и переменной длинной команд, не равной разрядности чего-либо. Разумеется, все современные ЦП внутри — настоящие RISC, но это только физически, а не архитектурно. Остались только два вида информации — данные и адреса. Их и рассмотрим.Собираем

У нас имеется три критерия видов разрядности: функциональный (обработки, хранения и обмена), реализационный (физическая и архитектурная) и типовой (данных и адресов). Итого уже 12 видов этой непонятной штуки. Предположим, что на каждую комбинацию критериев для нашего исходного ЦП мы отвечаем «16-битная» (и физическая разрядность обработки данных, и архитектурная хранения адресов, и все остальные). Теперь посмотрим, какие из этих вопросов обязательно должны давать ответ «32-битная», чтобы получившийся процессор оказался именно таким.

Начнём с архитектурной части. Должен ли ЦП хранить данные и адреса в логическом 32-битном формате, чтобы называться 32-битным? Насчёт данных, очевидно, да, а вот по поводу адресов всё не так просто. Почти все 8-битные (по данным) ЦП имеют возможность хранить 16-битные адреса в парах регистров (иначе им не видать распространённой на этих платформах 16-битной адресации), но от этого их не называют 16-битными. Может быть, если ЦП сможет хранить 32-битные данные, но всего-то 16-битные адреса, его уже можно называть 32-битным.

На аналогичные вопросы об архитектурных вычислениях над 32-битными данными и адресами, а также программно 32-битном обмене данных с программно 32-битной адресацией ответ может быть таким же — с данными надо, а с адресами не факт.

Перейдём на физическую реализацию. Должен ли ЦП хранить данные и адреса в физически 32-битном формате? Оказывается, не обязательно, т.к. для 32-битных операндов можно спарить регистры, чем успешно пользовались ещё 8-битные ЦП, начиная с i8080. А зилоговские 16-битные Z8000 могли даже счетверять регистры, получая 64-битный аргумент (только для данных). Это не так эффективно, т.к. полный объём данных, умещающийся в регистровом файле, не увеличится, но это и не требовалось. Зато всегда есть возможность обратиться и к старшей, и к младшей половине виртуального 32-битного регистра — камень в огороды архитектур IA-32 и MC68k, где можно обращаться только к младшей половине (в IA-32 — ещё и с префиксом, что замедляет выполнение).

Идём далее. Должен ли ЦП обрабатывать данные и адреса 32-битными физическими порциями? Оказывается, и это не требуется, операнды можно обрабатывать половинками в функциональных устройствах 16-битного размера. Стоит вспомнить процессор Motorola MC68000, применявшийся в первых Макинтошах, Амигах, Атари и других популярных машинах — он считался 32-битным, в нём есть 32-битные регистры, но нет ни одного 32-битного ФУ (оно появилось только в 68020). Зато есть целых три 16-битных АЛУ, два из которых умеют спариваться при выполнении 32-битной операции. У i8080 и Z80 8-битные АЛУ выполняли 16-битные операции для вычисления адреса последовательно над его байтами. Позже эта история повторилась с набором SSE и его 128-битными операндами, которые поначалу обрабатывались на 64-битных ФУ.

Наконец, обмен: нужно ли процессору физически принимать и передавать данные 32-битными порциями с 32-битной адресацией? На первый вопрос дали ответ почти все производители ЦП, выпустив чипы с половинной шириной шины: 8 бит для 16-битного i8088, 16 бит для 32-битных MC68000/010 и i80386SX/EX/CX, и даже 8 бит для 32-битного MC68008. С физической разрядностью шины адреса куда веселее. Начнём с того, что для многобайтовых шин данных (т.е. начиная с 16-битной) физическая адресация памяти может происходить по словам или по байтам. В первом случае на шину адреса всегда подаётся адрес слова, а шина данных считывает или записывает нужную его часть — от отдельного байта до слова целиком. Для обозначения разрядности доступа может применяться отдельная шина байт-маски (в архитектуре x86 такой приём начал применяться со времён i386 — по биту на каждый байт шины данных), либо комбинация управляющих сигналов с младшими битами шины адреса, которые в этом режиме не нужны (для 32-биной шины данных адрес слова нацело делится на 4, а потому младшие 2 бита шины адреса всегда равны нулю) — так было до выхода i386. Случай же адресации байтов возможен лишь при динамической подстройке ширины шины и из широко известных ЦП применялся только в MC68020/030. В результате к сегодняшнему дню используется именно адресация слов вместе с байт-маской, поэтому физическая разрядность шины адреса оказывается меньше её логической ширины на число бит, на единицу меньшее разрядности шины данных в байтах. Из чего следует, что 32-битная физическая шина адреса может быть только при 8-битной шине данных, на что ни один архитектор и инженер в здравом уме не пойдёт по очевидным соображениям.

Но это ещё не всё. Зачем нам вообще 32-битная физическая или логическая адресация? Середина-конец 80-х, на рынке только-только появились мегабитные микросхемы памяти, типичный объём памяти для ПК пока что измеряется сотнями килобайт, но чуть позже — мегабайтами. А 32-битная адресация позволит получить доступ к 4 ГБ физического ОЗУ! Да кому вообще такое может понадобиться в ближайшие лет 20 в персоналках?! Неудивительно, что первые популярные «32-битные» ЦП имели совсем не 32 бита логической ширины шины адреса: MC68000 имел 24 (23 физических + 1 для управления разрядами), а MC68008 — и вовсе 20. Intel 386SX (вышедший на 3 года позже оригинального полностью 32-битного i80386), помимо уполовинивания шины данных, сократил и шину адреса до 24 (23 физических) бит, а его встраиваемые версии 386EX/CX имели 26-битную шину. Более того, первые чипсеты, позволявшие оперировать 32-битными адресами, появились лишь в 90-х, а первые материнские платы, имевшие достаточное число слотов памяти, чтобы набрать >4 ГБ модулями максимального на тот момент размера — лишь в 2000-х. Хотя первые ЦП с 64-битной физической шиной адреса (IBM/Motorola PowerPC 620) появились аж в 1994 г.. Выводим

Итак, физически в процессоре вообще ничего не требуется делать 32-битным. Достаточно лишь архитектурно убедить программиста, что ЦП выполняет 32-битные операции одной командой. И хотя она при отсутствии полноценных внутренних ресурсов неизбежно будет декодироваться в цепочки микрокода для управления 16-битными физическими порциями информации и аппаратными блоками — это уже программиста не волнует. Так что же, достаточно переписать прошивку, переделать декодер и схему управления, и вот наш 16-битный процессор сразу стал 32-битным?

Как известно, любую хорошую идею можно довести до абсурда, и тогда она сама себя дискредитирует. Увеличение разрядности ЦП — не исключение. На этом месте архитектурщик сразу должен задаться вопросом — а зачем всё это? Увеличивать разрядность данных хорошо для ускорения работы с ними (часто требуется обрабатывать значения, не умещающиеся в 16 бит), а адресов — для получения возможности оперировать большими объёмами данных (ограничение в 64 КБ для 16-битной адресации, кое-как ослабленное сегментной моделью IA-16, сковывало программистов уже в середине 80-х). Можно, конечно, сделать страничную адресацию с программно переключаемыми банками (могли же 8-битные ЦП адресовать 1 МБ на популярных дешёвых ПК и игровых приставках), но ценой усложнения программ и замедления доступа к памяти. Аналогично — разве имеет смысл делать 32-битность для данных такой, что она почти не ускоряет производительность по сравнению с обработкой 32-битных чисел на 16-битной платформе под управлением программы, а не микрокода? Таким образом мы только упростим программирование, сэкономив на числе команд, но не получим скачок в скорости. Из чего мы приходим к выводу — увеличение разрядности должно реализовываться так, чтобы оно реально привело к качественному (больше памяти) и количественному (быстрее операции) скачку возможностей архитектуры. «Больше памяти» здесь относится именно к качественному развитию, т.к. многие алгоритмы и приложения вообще откажутся работать при недостатке ОЗУ, в то время как даже медленный процессор всё равно рано или поздно программу выполнит. Виртуальная память с дисковой подкачкой бессмысленна при менее чем 32-битной реализации.

Но означает ли всё это, что в ЦП как можно больше ресурсов, и аппаратных, и архитектурных, должны быть 32-битными, чтобы его можно было бы назвать полноценным 32-битным процессором? Совсем нет. Возьмём тот же MC68000 — у него 32-битная архитектура для данных и адресов и 32-битные регистры, но 16-битные АЛУ и внешняя шина данных и 24-битная физическая внешняя адресация. Тем не менее, недостаточная «32-битность» не мешает ему обгонять появившийся на 3 года позже «16-битный» 80286: на популярном в 1980-е бенчмарке Dhrystones MC68000 на 8 МГц набирает 2100 «попугаев», а 286 на 10 МГц — 1900 (также 16-битный i8088 на 4,77 МГц — 300).

Но всё это нам не поможет ответить на вопрос — что же такое разрядность процессора? В момент, когда мы уже было пришли к некоему заключению, на сцене появляется новый герой — тип данных. Всё вышеизложенное имело отношение лишь к целочисленным вычислениям и их аргументам. Но ведь есть ещё и вещественные. Кроме того, пока что мы оперируем скалярными величинами, но есть ещё и векторные. А ведь, по слухам, Intel намерена встроить вещественный сопроцессор прямо внутрь своего нового 80486 (напомню: на дворе у нас, условно — 80-е годы). С учётом того, что внутреннее физическое и архитектурное представление данных (с адресами FPU не работает) 80-битное — как же тогда называть «четвёрку» — «32/80-битным» процессором? Вернёмся обратно в настоящее — как называть Pentium MMX, который откусил 64 бита от каждого 80-битного скалярного вещественного регистра и назвал их целочисленным векторным регистром? А Pentum Pro/II с 256-битной шиной данных между кэшем L2 и ядром? (Ещё ранее MIPS R4000 и его варианты имели внутренний контроллёр L2 с внешней 128-битной шиной до самого кэша.) А как назвать Pentium III с его 128-битными регистрами XMM, хотя в каждом таком векторе могут пока храниться лишь 32-битные компоненты, а обрабатываться лишь парами в 64-битных ФУ, но не четвёрками? А как воспринимать готовящиеся сейчас для новых архитектур (в частности, Intel Larrabee) команды векторной адресации типа Scatter и Gather, где части векторного регистра воспринимаются как адреса, а не данные, и потому адресация тоже может считаться ххх-битной?

Современный спор о переходе с 32-битной на 64-битную платформу повторяет эту историю с дополнениями, ещё более подсаливающими и так разнообразное по вкусу блюдо. Прежде всего, если посмотреть на темпы удвоения разрядности (что бы под ней не понимали) однокристальных ЦП, то окажется, что переход от первых 4-битных к первым 32-битным произошёл всего за 8 лет — c 1971 г. (i4004) по 1979 г. (MC68000 и куда менее известный NS32016). Следующее удвоение до 64 бит потребовало 10 лет — i860 имел 32-битное целое скалярное АЛУ и 32-битные универсальные регистры со спариванием, но 64-битные FPU и целочисленное векторное ФУ, 64-битные внешние шины и, впервые, внутреннюю 128-битную шину ядро-кэш. А пока 64 бита добрались до ПК — прошло ещё лет 15, хотя 64-битный доступ к памяти (через 64-битную же шину данных, но для «32-битного» процессора) появился уже в первых Pentium в 1993 г.. А дело в том, что для целочисленных скалярных вычислений два главных типа операндов — данные и адреса — пока достаточно было иметь лишь 32-битными. Об избыточности 32-битной адресации для 80-90-х гг. уже сказано, но и жёсткая необходимость в 64-битных целочисленных вычислениях, в отличие от 32-битных, также до сих пор не возникала, да и не просматривается и сейчас. Для целых чисел диапазон от –2·10 9 до 2·10 9 или от 0 до 4·10 9 покрывает подавляющее большинство нужд, а редкие моменты 64-битности вполне удовлетворяются дедовским способом — операциями над частями операндов с переносом, что не так уж сильно медленнее и доступно с первых моментов появления 32-битных архитектур. Дополнительной пикантности добавляет тот факт, что 64-битная арифметика над целыми числами в архитектуре x86 появились ещё до AMD64 и EM64T, причём сразу векторная — начиная с набора SSE2 (2001 г.) существуют команды paddq и psubq для сложения и вычитания целых 64-битных компонентов, а команды 32-битного перемножения для любой архитектуры дают 64-битное число (команды деления, соответственно — его принимают; аналогично для многих 16-битных платформ, включая IA-16).

Разрядности некоторых процессоров для ПК

* — Мультиплексированная шина данных и адреса (для ЦП с интегрированным контроллёром памяти — только межпроцессорная)
«A/B|C/D» — для данных указана разрядность скалярного целого / вещественного | векторного целого / вещественного доменов
«X+Y» — имеет домены этого вида двух разрядностей
«X-Y» — в зависимости от команды или ФУ принимает все промежуточные значения с целой степенью двойки

Если вы дочитали до этого места, то объявленная цель статьи, скорее всего, уже достигнута, а Идеальное Конечное Точное Определение разрядности так и не найдено. Может быть, его вообще нет, и это даже хорошо. В конце концов, если компьютер это главный инструмент для работы с информацией, то каждая IT-технология это метод улучшения работы компьютера. Разрядность сама по себе ничего не даст в отрыве от всего остального арсенала высоких инфотехнологий. PDA/коммуникаторы, мобильники, нетбуки, медиа-плееры и прочая карманная электроника, а также гигантское количество встроенных контроллёров и бортовых компьютеров отлично работают, увеличивая свою популярность и без всякой 64-битности. Так зачем тогда переходят на большие разрядности? Зачем, например, никому пока не нужная 64-битность в Intel Atom для нетбуков, где 8 ГБ памяти мало того, что никому не нужны, так ещё и за пару часов досуха выжмут батарею, а научные или экономические вычисления (где могут потребоваться 64 целых бита) никто запускать не будет? Один из возможных ответов: «потому что мы можем». Дополнительная пара миллионов транзисторов для удвоения ещё оставшихся 32-битными блоков утонет каплей в море вентилей, уже потраченных на всё остальное в этом же чипе. Галопирующий прогресс микроэлектроники как главного паровоза IT сделал интегральный транзистор таким дешёвым, что теперь лакомый для любого маркетолога шильдик «64 bit» обойдётся потребителю в десяток лишних центов, обеспечивая совсем не бутафорское, а вполне реальное ускорение на 10-50 % в 1-5 % приложений. И если мелкая овчинка стоит почти бесплатной выделки, почему нет?

Источник