Почему x86 уродлив? Почему он считается низшим по сравнению с другими?

Пара возможных причин:

1. x86 — это относительно старая ISA (в конце концов, ее предшественниками были 8086)
2. x86 значительно эволюционировал несколько раз, но для обеспечения обратной совместимости со старыми двоичными файлами требуется аппаратное обеспечение. Например, современное оборудование x86 по-прежнему поддерживает работу с 16-битным кодом. Кроме того, существует несколько моделей адресации памяти, позволяющих более старому коду взаимодействовать на одном и том же процессоре, например реальный режим, защищенный режим, виртуальный режим 8086 и длинный режим (amd64). Некоторых это может сбить с толку.
3. x86 - это машина CISC. Долгое время это означало, что он был медленнее, чем RISC-машины, такие как MIPS или ARM, потому что инструкции имеют взаимозависимость данных и флаги, что делает большинство формы параллелизма на уровне инструкций трудно реализовать. Современные реализации переводят инструкции x86 в RISC-подобные инструкции, называемые "micro-ops" под обложки, чтобы сделать эти виды оптимизации практичными для аппаратной реализации.
4. В некоторых отношениях x86 не уступает, он просто другой. Например, ввод/вывод обрабатывается как отображение памяти на подавляющем большинстве архитектур, но не на x86. (Примечание: современные машины x86 обычно имеют ту или иную форму поддержки DMA и взаимодействуют с другим оборудованием через память. сопоставление; но ISA по-прежнему имеет инструкции ввода-вывода, такие как IN и OUT)
5. x86 ISA имеет очень мало архитектурных регистров, что может заставить программы выполнять циклический обход памяти чаще. чаще, чем это было бы необходимо. Дополнительные инструкции, необходимые для этого, требуют ресурсов выполнения, которые можно было бы потратить на полезную работу, хотя эффективная переадресация хранилища снижает задержку. Современные реализации с переименованием регистров в большой файл физических регистров могут поддерживать выполнение многих инструкций, но отсутствие архитектурных регистров по-прежнему было существенным недостатком 32-разрядной архитектуры x86. Увеличение x86-64 с 8 до 16 целочисленных и векторных регистров является одним из самых важных факторов в том, что 64-битный код работает быстрее, чем 32-битный (наряду с более эффективным ABI-вызовом регистров), а не увеличенной шириной каждого регистра. Некоторым помогло бы дальнейшее увеличение числа регистров с 16 до 32, но не так сильно. (Однако AVX512 увеличивает число векторных регистров до 32, поскольку код с плавающей запятой имеет более высокую задержку и часто требует большего количества констант.) (см. комментарий)

6. Ассемблерный код x86 сложен, потому что x86 — это сложная архитектура с множеством функций. Список инструкций для типичной машины MIPS умещается на листе бумаги размером с одну букву. Эквивалентный листинг для x86 занимает несколько страниц, а инструкции просто делают больше, поэтому вам часто требуется более подробное объяснение того, что они делают, чем может дать листинг. Например, MOVSB инструкции требуется относительно большой блок кода C, чтобы описать, что оно делает:

   if (DF==0) 
     *(byte*)DI++ = *(byte*)SI++; 
   else 
     *(byte*)DI-- = *(byte*)SI--;
   

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

   Хотя простота MIPS (и подобных архитектур) не обязательно делает их превосходными, для обучения введению в класс ассемблера имеет смысл начать с более простого ISA. На некоторых занятиях по ассемблеру преподается сверхупрощенное подмножество x86, называемое y86, которое настолько упрощено, что не является полезно для реального использования (например, без инструкций сдвига), или некоторые обучают только основным инструкциям x86.

7. В x86 используются операционные коды переменной длины, которые усложняют аппаратное обеспечение в отношении разбора инструкций. В современную эпоху эта стоимость становится исчезающе малой, поскольку процессоры все больше и больше ограничиваются пропускной способностью памяти, а не необработанными вычислениями, но многие статьи и мнения, посвященные критике x86, исходят из эпохи, когда эта стоимость была сравнительно намного выше.
   Обновить 2016 г.: Anandtech опубликовала обсуждение размеров кода операции для x64 и AArch64.

РЕДАКТИРОВАТЬ: Это не должна быть вечеринка bash the x86!. У меня не было другого выбора, кроме как немного поиздеваться над тем, как сформулирован вопрос. Но за исключением (1) все эти вещи были сделаны по уважительным причинам (см. комментарии). Разработчики Intel не глупы — они хотели чего-то достичь с помощью своей архитектуры, и вот некоторые налоги, которые им пришлось заплатить, чтобы воплотить эти цели в жизнь.

На мой взгляд, основным недостатком x86 является его происхождение из CISC — набор инструкций содержит множество неявных взаимозависимостей. Эти взаимозависимости затрудняют выполнение таких операций, как переупорядочивание инструкций на микросхеме, потому что артефакты и семантика этих взаимозависимостей должны сохраняться для каждой инструкции.

Например, большинство инструкций сложения и вычитания целых чисел x86 изменяют регистр флагов. После выполнения сложения или вычитания следующей операцией часто является просмотр регистра флагов для проверки переполнения, знакового бита и т. д. Если после этого есть еще одно сложение, очень сложно сказать, безопасно ли начинать выполнение второго сложения. до того, как станет известен результат 1-го добавления.

В архитектуре RISC инструкция добавления будет указывать входные операнды и выходные регистры, и все, что касается операции, будет выполняться с использованием только этих регистров. Это значительно упрощает разделение операций добавления, которые находятся рядом друг с другом, потому что нет регистра флагов распускания, заставляющего все выстраиваться в линию и выполнять один файл.

Чип DEC Alpha AXP, дизайн RISC в стиле MIPS, был болезненно спартанским в доступных инструкциях, но набор инструкций был разработан, чтобы избежать неявных зависимостей регистров между инструкциями. Аппаратно-определяемого стекового регистра не было. Не было регистра аппаратно-определяемых флагов. Даже указатель инструкций был определен ОС — если вы хотели вернуться к вызывающей стороне, вам нужно было решить, как вызывающая сторона сообщит вам, по какому адресу следует вернуться. Обычно это определялось соглашением о вызовах ОС. Однако на x86 это определяется аппаратным обеспечением чипа.

Как бы то ни было, за 3 или 4 поколения чипов Alpha AXP аппаратное обеспечение превратилось из буквальной реализации спартанского набора инструкций с 32 регистрами int и 32 регистрами с плавающей запятой в чрезвычайно неупорядоченный исполнительный механизм с 80 внутренними регистрами, переименованием регистров, переадресация результата (где результат предыдущей инструкции перенаправляется в более позднюю инструкцию, которая зависит от значения) и всевозможные дикие и сумасшедшие ускорители производительности. И со всеми этими прибамбасами кристалл AXP все еще был значительно меньше, чем сопоставимый кристалл Pentium того времени, и AXP был чертовски быстрее.

Вы не видите таких всплесков повышения производительности в генеалогическом дереве x86 в основном потому, что сложность набора инструкций x86 делает многие виды оптимизации выполнения непомерно дорогими, если не невозможными. Гениальный ход Intel состоял в том, что он отказался от реализации набора инструкций x86 в аппаратном обеспечении - все современные чипы x86 на самом деле являются RISC-ядрами, которые в определенной степени интерпретируют инструкции x86, переводя их во внутренний микрокод, который сохраняет всю семантику исходного x86. инструкции, но позволяет немного этого RISC не по порядку и других оптимизаций по сравнению с микрокодом.

Я много писал на ассемблере x86 и могу полностью оценить удобство его корней CISC. Но я не осознавал в полной мере, насколько сложным был x86, пока не потратил некоторое время на написание ассемблера Alpha AXP. Я был ошеломлен простотой и единообразием AXP. Различия огромны и глубоки.

Архитектура x86 восходит к конструкции микропроцессора 8008 и его родственников. Эти ЦП были разработаны в то время, когда память была медленной, и если вы могли сделать это на кристалле ЦП, часто это было намного быстрее. Однако место на кристалле ЦП также было дорогим. Эти две причины объясняют, почему существует лишь небольшое количество регистров, которые, как правило, имеют специальное назначение, и сложный набор инструкций со всевозможными подводными камнями и ограничениями.

Другие процессоры той же эпохи (например, семейство 6502) также имеют аналогичные ограничения и особенности. Интересно, что и серия 8008, и серия 6502 были задуманы как встроенные контроллеры. Даже в то время ожидалось, что встроенные контроллеры будут программироваться на ассемблере, и во многих отношениях они были ориентированы на программиста на ассемблере, а не на автора компилятора. (Посмотрите на микросхему VAX, чтобы узнать, что происходит, когда вы обслуживаете запись компилятора.) Разработчики не ожидали, что они станут вычислительными платформами общего назначения; для этого и были созданы предшественники архитектуры POWER. Революция домашних компьютеров, конечно же, изменила это.

У меня есть несколько дополнительных аспектов:

Рассмотрим операцию «a=b/c», которую x86 реализует как

  mov eax,b
  xor edx,edx
  div dword ptr c
  mov a,eax

В качестве дополнительного бонуса инструкция div edx будет содержать остаток.

Процессору RISC потребуется сначала загрузить адреса b и c, загрузить b и c из памяти в регистры, выполнить деление и загрузить адрес a, а затем сохранить результат. Синтаксис DST,SRC:

  mov r5,addr b
  mov r5,[r5]
  mov r6,addr c
  mov r6,[r6]
  div r7,r5,r6
  mov r5,addr a
  mov [r5],r7

Здесь обычно не будет остатка.

Если какие-либо переменные должны быть загружены через указатели, обе последовательности могут стать длиннее, хотя это менее вероятно для RISC, поскольку он может иметь один или несколько указателей, уже загруженных в другой регистр. x86 имеет меньше регистров, поэтому вероятность того, что указатель находится в одном из них, меньше.

Плюсы и минусы:

Инструкции RISC могут быть смешаны с окружающим кодом для улучшения планирования инструкций, это меньше возможностей для x86, который вместо этого работает (более или менее хорошо, в зависимости от последовательности) внутри самого ЦП. Приведенная выше последовательность RISC обычно имеет длину 28 байт (7 инструкций шириной 32 бита/4 байта каждая) в 32-битной архитектуре. Это заставит внешнюю память работать больше при выборке инструкций (семь выборок). Более плотная последовательность x86 содержит меньше инструкций, и хотя их ширина различается, вы, вероятно, тоже смотрите на среднее значение 4 байта на инструкцию. Даже если у вас есть кэши инструкций для ускорения этого, семь выборок означают, что у вас будет дефицит в три в другом месте, чтобы компенсировать по сравнению с x86.

Архитектура x86 с меньшим количеством регистров для сохранения/восстановления означает, что она, вероятно, будет переключать потоки и обрабатывать прерывания быстрее, чем RISC. Большее количество регистров для сохранения и восстановления требует больше временного пространства стека ОЗУ для выполнения прерываний и больше постоянного пространства стека для хранения состояний потоков. Эти аспекты должны сделать x86 лучшим кандидатом для запуска чистой RTOS.

Если говорить более лично, мне кажется, что писать RISC-ассемблер сложнее, чем x86. Я решаю эту проблему, написав процедуру RISC на C, скомпилировав и модифицировав сгенерированный код. Это более эффективно с точки зрения создания кода и, вероятно, менее эффективно с точки зрения выполнения. Все эти 32 регистра, которые нужно отслеживать. С x86 все наоборот: 6-8 регистров с "настоящими" именами делают проблему более управляемой и вселяют больше уверенности в том, что полученный код будет работать так, как ожидается.

Уродливый? Это в глазах смотрящего. Я предпочитаю "другое".

Я думаю, что этот вопрос имеет ложное предположение. В основном только ученые, одержимые RISC, называют x86 уродливым. В действительности x86 ISA может выполнять операции с одной инструкцией, которые потребовали бы 5-6 инструкций на ISA RISC. Поклонники RISC могут возразить, что современные процессоры x86 разбивают эти «сложные» инструкции на микрооперации; Однако:

1. Во многих случаях это правда лишь частично или совсем не соответствует действительности. Наиболее полезными «сложными» инструкциями в x86 являются такие вещи, как mov %eax, 0x1c(%esp,%edi,4), то есть режимы адресации, и они не разбиты на части.
2. На современных машинах часто важнее не количество затраченных циклов (поскольку большинство задач не связаны с процессором), а влияние кода на кэш инструкций. 5-6 инструкций фиксированного размера (обычно 32-битных) повлияют на кеш намного больше, чем одна сложная инструкция, которая редко превышает 5 байт.

x86 действительно впитал в себя все хорошие стороны RISC лет 10-15 назад, а остальные качества RISC (собственно определяющее - минимальный набор инструкций) вредны и нежелательны.

Помимо стоимости и сложности производства ЦП и их энергопотребления, x86 является лучшей ISA. Любой, кто говорит вам обратное, позволяет идеологии или повестке дня мешать их рассуждениям.

С другой стороны, если вы ориентируетесь на встроенные устройства, для которых важна стоимость ЦП, или встроенные/мобильные устройства, для которых энергопотребление является главной проблемой, ARM или MIPS, вероятно, имеют больше смысла. Имейте в виду, что вам все равно придется иметь дело с дополнительной оперативной памятью и размером двоичного файла, необходимым для обработки кода, который легко в 3-4 раза больше, и вы не сможете приблизиться к производительности. Имеет ли это значение, во многом зависит от того, что вы будете на нем запускать.

Язык ассемблера x86 не так уж плох. Когда вы добираетесь до машинного кода, он начинает становиться действительно уродливым. Кодировки инструкций, режимы адресации и т. д. намного сложнее, чем для большинства процессоров RISC. Кроме того, в целях обратной совместимости встроены дополнительные функции, которые срабатывают только тогда, когда процессор находится в определенном состоянии.

Например, в 16-битных режимах адресация может показаться совершенно странной; есть режим адресации для [BX+SI], но нет для [AX+BX]. Такие вещи, как правило, усложняют использование регистров, поскольку вам необходимо убедиться, что ваше значение находится в регистре, который вы можете использовать по мере необходимости.

(К счастью, 32-битный режим намного разумнее (хотя иногда он сам по себе немного странный — например, сегментация), а 16-битный код x86 больше не имеет значения за пределами загрузчиков и некоторых встроенных сред.)

Есть также пережитки прошлых дней, когда Intel пыталась сделать x86 совершенным процессором. Инструкции длиной в пару байтов, которые выполняли задачи, которые на самом деле больше никто не делает, потому что они, откровенно говоря, были чертовски медленными или сложными. Инструкции ENTER и LOOP, для двух примеров - обратите внимание, что код фрейма стека C похож на "push ebp; mov ebp, esp", а не на "enter" для большинства компиляторов.

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

Я думаю, что параллелизм — один из самых важных факторов в наши дни — по крайней мере, для алгоритмов, которые уже работают достаточно быстро, чтобы их можно было использовать. Выражение высокого параллелизма в программном обеспечении позволяет аппаратному обеспечению амортизировать (или часто полностью скрывать) задержки памяти. Конечно, далеко идущее архитектурное будущее, вероятно, связано с чем-то вроде квантовых вычислений.

Я слышал от nVidia, что одной из ошибок Intel было то, что они держали двоичные форматы близко к оборудованию. CUDA PTX выполняет несколько быстрых вычислений использования регистров (раскрашивание графика), поэтому nVidia может использовать регистровую машину вместо стековой, но при этом иметь путь обновления, который не ломает все старое программное обеспечение.

Помимо причин, которые люди уже упоминали:

• В x86-16 была довольно странная схема адресации памяти, которая позволяла адресовать одну ячейку памяти в до 4096 различных способов, ограничение оперативной памяти до 1 МБ и вынуждают программистов иметь дело с указателями двух разных размеров. К счастью, переход на 32-разрядную версию сделал эту функцию ненужной, но чипы x86 по-прежнему несут в себе основную часть сегментных регистров.
• Хотя это и не является ошибкой x86 как таковой, соглашения о вызовах x86 не были стандартизированы, как MIPS (в основном потому, что MS-DOS не поставлялась с компиляторами), оставляя нас с беспорядком __cdecl, __stdcall , __fastcall и т. д.

Я думаю, вы получите часть ответа, если когда-нибудь попытаетесь написать компилятор, ориентированный на x86, или если вы напишете эмулятор машины x86, или даже если вы попытаетесь внедрить ISA в аппаратное обеспечение.

Хотя я понимаю "x86 некрасиво!" аргументы, я по-прежнему думаю, что весело писать ассемблер x86, чем MIPS (например) - последнее просто утомительно. Это всегда предназначалось для компиляторов, а не для людей. Я не уверен, что чип мог бы быть более враждебным по отношению к авторам компиляторов, если бы попытался...

Самое неприятное для меня — это то, как работает сегментация (в реальном режиме): любой физический адрес имеет 4096 псевдонимов сегмент: смещение. Когда в последний раз вам это было нужно? Все было бы намного проще, если бы часть сегмента была строго старшими битами 32-битного адреса.

1. x86 имеет очень, очень ограниченный набор регистров общего назначения.

2. он продвигает очень неэффективный стиль разработки на самом низком уровне (ад CISC) вместо эффективной методологии загрузки/хранения.

3. Intel приняла ужасающее решение ввести откровенно глупую модель адресации сегмента/смещения памяти, чтобы оставаться совместимой с (уже на данный момент!) устаревшей технологией.

4. В то время, когда все переходили на 32-битные, x86 сдерживал массовый мир ПК, будучи скудным 16-битным (большинство из них — 8088 — даже только с 8-битными внешними путями данных, что еще страшнее!)

Для меня (и я ветеран DOS, который видел каждое поколение ПК с точки зрения разработчиков!) пункт 3 был худшим.

Представьте себе следующую ситуацию, которая была у нас в начале 90-х (мейнстрим!):

а) Операционная система с безумными ограничениями по устаревшим причинам (640 КБ легкодоступной оперативной памяти) - DOS

б) Расширение операционной системы (Windows), которое могло больше работать с оперативной памятью, но было ограничено, когда дело доходило до таких вещей, как игры и т. д., и не было самой стабильной вещью на Земле (к счастью, это изменилось позже, но я я про начало 90-х)

c) Большая часть программного обеспечения все еще была DOS, и нам приходилось часто создавать загрузочные диски для специального программного обеспечения, потому что был этот EMM386.exe, который некоторым программам нравился, другим ненавидели (особенно геймерам - а я в то время был AVID геймером - знаете, что я я про вот это)

г) Мы были ограничены MCGA 320x200x8 бит (ладно, там было немного больше со специальными ухищрениями, 360x480x8 было возможно, но только без поддержки библиотеки времени выполнения), все остальное было грязно и ужасно ("VESA" - лол)

д) Но с точки зрения железа у нас были 32-битные машины с несколькими мегабайтами ОЗУ и картами VGA с поддержкой до 1024x768.

Причина такой плохой ситуации?

Простое дизайнерское решение Intel. Уровень машинных инструкций (НЕ двоичный уровень!) Совместимость с чем-то, что уже умирало, я думаю, что это был 8085. Другие, казалось бы, не связанные проблемы (графические режимы и т. д.) были связаны с техническими причинами и из-за очень узкого Недалеко мыслящую архитектуру платформа x86 принесла с собой.

Сегодня ситуация иная, но спросите любого разработчика ассемблера или людей, которые создают серверные части компилятора для x86. Безумно малое количество регистров общего назначения — не что иное, как ужасный убийца производительности.