ISA ошибок не прощает

    –X86 – это исторически сложившееся недоразумение,– мэтр и в 80 не утратил полемического задора.
    – Вообще-то ей принадлежит 95% серверного рынка, – вяло откликнулся я. Мне не хотелось вступать в спор на сто раз заезженную тему
    – А я уже запутался в этих префиксах, — не унимался академик. – 15 байт на инструкцию, это немыслимо!
    – Ну, не ice, конечно. Но у кого лучше-то?
    – Да у кого угодно, хотя бы у ARM-a.
    – Я все же не понимаю. Cложения с умножениями должны быть?
    – Должны.
    – И сдвиги c логическими операциями?
    – Да.
    – И загрузки с сохранениями тоже. Какая разница как они называются и кодируются?

    Как обычно, правоту учителя я осознал много позже. Когда тоскливым зимним вечером сел писать декодер команд, чтобы как то себя развлечь. Простенький декодер для ARM мне удалось изобразить на VHDL (а знаю я его так себе) за пару дней. Правда, каюсь, у меня была шпаргалка. :)

    image

    Для X86 не удалось ни за неделю, ни за две, ни за месяц… Даже для базового набора.

    Разница здесь даже не только в RISC (Reduced Instruction Set Computing) для ARM и CISC (Complex Instruction Set) для X86. Разница скорее в пути исторического развития. Больше 40 лет назад, а началось все в 1978 году, X86 ISA (Instruction Set Architecture) была вполне себе компактным набором команд со своей внутренней логикой. Но время шло, росла разрядность шин, расширялись регистры (включая SIMD), перманентно возрастало число команд. Тут один паренёк сделал интересную попытку просто посчитать число инструкций в Х86. То ли ему лень было открывать мануал и считать их, то ли он знал о существовании “безымянных” опкодов (команд, у которых даже названия нет), то ли верил во всемогущество логики. Как легко понять, логика оказалась бессильна. :) Кстати, я пытался найти график роста числа X86 инструкций по годам (или по поколениям). Пока не смог (может, есть у кого?). Зато нашел вот такую картинку.

    image

    Если честно, я не знаю, сколько сейчас в X86 ISA инструкций. Но хорошо помню все те, в разработку которых сам вкладывался, при этом не отдавая себе отчета в том, что каждый новый бит в ISA снабжается ярлыком “хранить вечно”. А «творцов» вроде меня в Intel было несколько тысяч. И битов для того, чтобы закодировать все их фантазии постоянно не хватало. :) К существующему набору команд добавлялись все новые префиксы: REX, VEX… Последнее четырехбайтовое (EVEX) расширение было введено для AVX-512. К слову, весь набор команд АRM (даже с учетом SVE) убирается в эти самые 4 байта. ARM изначально пошел другим путем, строя свою систему команд на базовых принципах простоты, компактности и расширяемости.

    Разницу можно понять, если перейти с точки зрения программиста на точку зрения circuit designer. А она как известно состоит в том, что транзистор – отличная вещь, но переключается медленно, а энергию рассеивает безбожно. И при прочих равных, лучше бы их было поменьше. А теперь взгляните на алгоритм декодирования x86 инструкций(та задача, которую я пытался решить).

    image

    И, как говорится, почувствуйте разницу во входных трактах (front end) для ARM и X86. Тут можно возразить, что front end – это совсем небольшая часть ядра, всего около 10%. Да, но не надо забывать, что вся эта логика умножается ещё на количество ядер на чипе. А это уже серьезно.

    Eщё одно соображение, что front end – как раз та часть, которая ответственна за backward compatibility. Вы можете смело перелопатить или даже выкинуть back end. Intel, кстати, воспользовался этим в начале 2000-х, заменив архитектуру NetBurst (P4) на Core-M (P3). А вот front end сильно сократить не удастся. Хотя иногда очень хочется, потому что из существующей X86 ISA сейчас используется около 20%. Остальное – пережитки прошлого.

    Другой недостаток огромной длины инструкций – относительно частые промахи в instruction cache. Грубо говоря, при равном размере кэшей, количество промахов будет тем больше, чем больше длина инструкции. Конечно, размер кэшей можно увеличивать. Но опять же, это транзисторы, которых могло бы не быть, будь инструкции покороче. По этой же причне я очень настороженно отношусь к разного рода VLIW (Very Long Instruction World) архитектурам. Впрочем, они обладают еще и тем недостатком, что для них очень сложно разрабатывать компиляторы. Тему компиляторов я до сего момента сознательно избегал, поскольку сам никогда их не разрабатывал. Хотелось бы послушать, что скажут знающие люди о прелестях разработки компиляторов для RISC, CISC и VLIW.

    И все же, несмотря на огромный накопленный груз legacy, а может быть и благодаря ему, разработчики X86 оказались правы в главном. Принцип backward compatibility свято соблюдается в архитектуре с самого начала. Весь существующий софт работает на новом железе «из коробки». Именно это позволило построить столь глубокую и развитую экосистему вокруг архитектуры. И остается только снять шапку перед инженерами Intel и AMD, которые вопреки отнюдь не идеальному дизайну ISA, на протяжении многих лет сохраняют лидерство в серверном сегменте. Однако, груз legacy становится все тяжелее.
    Huawei
    Компания

    Комментарии 384

      +5

      У Intel было много ISA, как минимум с десяток. Ни одна, кроме x86 не выстрелила, увы.

        +12
        Горестная судьба Itaniuma вся прошла перед моими глазами. Поделка, впрочем не была так плоха чтоб с первого дня окрестить ее Itanicом. Однако, это EPIC…
          +2
          А глубинная причина, кстати, в тех же словах: «backward compatibility». Которая была заявлена, но на практике не работала. Ну и VLIW опять же, еще ни одна VLIW-архитектура по-настоящему не взлетела.
            0
            Зато энергию этот backward compatibility блок потреблял за троих :)
              +1
              Внезапно, как раз Huawei и пытается продвигать собственные VLIW-архитектуры: www.zdnet.com/article/amazon-huawei-efforts-show-move-to-ai-centric-chips-continues
                +1
                Для очень специфических задач, а вовсе не для процессоров общего назначения.
                Так то есть несколько VLIW архитектур (не Эльбрус), которые вполне живы — например ST2XX встречаются в спутниковых ресиверах.
                  +1
                  Qualcomm Hexagon живее всех живых: наверное, в большинстве смартфонов стоит.

                  Мне просто показалось забавным, что VLIW хоронят в блоге Huawei, которая один из нынешних активистов VLIW-строения.
                    0
                    Qualcomm Hexagon

                    Да, все это из области DSP-like процессоров, не более.
                0
                и одна VLIW-архитектура по-настоящему не взлетела.


                Qualcomm Hexagon. Используется, наверное, в половине мобильных устройств по всему миру. А это многие миллиарды девайсов.
                  +1
                  Давайте не смешивать процессоры общего назначения и специализированные контроллеры. А то так можно дойти до того, что AVR+PIC окажутся самыми распространенными процессорными архитектурами.
                    +2
                    Нет, давайте смешивать. Потому что прошивка модема это процентов на 90 самое обычное прикладное ПО. И размер его огромен. В несколько раз больше ядра линукса. Там и OS есть, и задачи (несколько десятков!), и примитивы синхронизации, сигналы, сисколлы, привилегии и т.д. Даже подкачка виртуальной памяти. Ту же самую OS Qualcomm собирал и под ARM. Не вижу особых различий в исполнении обычного прикладного кода. А в 2016 туда ещё и прикладную часть WiFi запихнули.
                      0
                      Как на этой прошивке запустить сторонний код? Чтобы просто почувствовать тот факт, что есть некий процессор, на котором работают программы, а не просто электронный модуль на плате, в который по одним ножкам электрические сигналы входят, а по другим — выходят.

                      «Глубокий» embed с точки зрения внешнего наблюдателя ничем не отличается от полностью аппаратной реализации. Поэтому внутренняя архитектура таких вещей не важна. Как, например, прошивка контроллера в клавиатуре компьютера совершенно не заметна даже системному программисту, не говоря уже про прикладника.
              0

              Интересно, а в какой момент это стало понятно? Или просто x86 доросла до того, чтобы на ней можно стало делать критически важные (или как там точно) вычисления? Помню, в каком-то поколении Xeon научился откатыааться с синего экрана.

              +3
              ЕМНИП, x86 разрабатывалась «на скорую руку» как временная, а основной должна была стать iAPX 432
                +4
                :) Я тоже слышал эту байку. Не уверен, что правда, оч давно было. Но хорошо коррелирует с мыслью о том, что в истории X86 гораздо большую роль играло стечение обстоятельств, чем изначально заложенная логика :)
                  +3
                  Это не байка.
                  «Stephen Morse: Father of the 8086 Processor»
                  www.pcworld.com/article/146917/article.html
                  management decided that I would be the ideal person to design the architecture for the stopgap measure. If management had any inkling that this architecture would live on through many generations and into today’s Pentium processors, and be the instruction set executed by more instances of computers than any other in history by far, they never would have entrusted the task to a single person.


                  Или вот ещё момент оттуда, про порядок байт, если кому лень читать статью:
                  I always regret that I didn’t fix up some idiosyncrasies of the 8080 when I had a chance. For example, the 8080 stores the low-order byte of a 16-bit value before the high-order byte.

                  Now there was no reason for me to continue this idiocy, except for some obsessive desire to maintain strict 8080 compatibility. But if I had made the break with the past and stored the bytes more logically, nobody would have objected. And today we wouldn’t be dealing with issues involving big-endian and little-endian—the concepts just wouldn’t exist.
                    0
                    And today we wouldn’t be dealing with issues involving big-endian and little-endian—the concepts just wouldn’t exist.

                    Ну, вообще-то, little endian порядок байт в слове был и в архитектурах весьма распространенных в те времена миникомпьютеров от DEC — PDP-11 и VAX-11. Так что насчет того, что концепции разных порядков байтов не существовали бы — это автор, наверное, всё же погорячился.
                    PS Правда, у этих концепций тогда был бы шанс не дожить до нашего времени — может, он это имел в виду?
                      +4

                      Были архитектуры, где правильно выбранный порядок байт упрощал или ускорял работу процессора. Были — где наоборот, замедлял. И были же — те, где на него пофиг было процессору. примеры:


                      1. pdp-11: процессор 16-битный и слова всегда выровнены по 2 байта. на порядок байт в слове пофиг, сделали LE.
                      2. i8080: процессор 8-битный, но читает 16-битные слова всегда как 2 подряд идущих байта. тоже на порядок байтов пофиг, сделали LE
                      3. mc6800 (не путать с mc68000!). 8-битный, порядок байт BE. за что расплата лишним тактом в адресации типа LDA ADDR,X, где процессор побайтно читает 16-битное число, прибавляет к нему 8-битный индексный регистр и с полученным адресом выходит на шину прочитать аргумент. порядок байт выбран неправильно (почему — см. ниже)
                      4. 6502! идеологически похож на 6800, порядок байт LE. благодаря этому, в описанном в п.3 случае читает сначала младший байт, потом во время чтения старшего — одновременно прибавляет к уже прочитанному индексный регистр. и если нет переноса в старшую часть, то на шину выходит сразу же, не тратя дополнительный такт. порядок байт выбран верно!

                      ну и соглашусь, что уже в i8086, mc68000 и далее — порядок байт перестал играть какую-либо роль. например архитектура ARMv7A позволяет переключать порядок байт прям в пользовательской программе, инструкциями SETEND BE/LE.

                        0

                        У PDP-11 не little endian, а PDP endian

                          0

                          "pdp endian" относится только к опциональному FPU. сам PDP-11 без FPU чисто 16-битная машина и соотв-но может быть назван little endian

                            0

                            Например, в DSP TigerSHARK 32битная архитектура. В смысле там даже char 32 бита. Там вообще нигде не вылезает endianess, кроме как при взаимодействии с переферией. Но для ALU это бессмысленно.

                        0
                        Вот что подумал — arm — консорциум вендоров. А Интел — одна компания. И решения в ней принимает гораздо меньшее число людей. А людям свойственно ошибаться. И поэтому в x86 гораздо больше странных решений…
                          0
                          Какой-то интересный баг Хабра, ваш этот коммент показывает не под тем комментарием, на который идёт ссылка как «предыдущий комментарий»
                            0
                            Прямо сейчас над вашим комментарием отображается три полностью пустых.
                            Всё чудесатее и чудесатее!
                              +1
                              это я поломал хабр(
                              я ответил на глючный коммент…
                              0
                              Н-да. Занятно. Я тот комментарий писал к комментарию про Стивена Морса и его высказывания как он боролся с 8086 в одно личико.
                              0
                              Что? А британцы из ARM Holdings в курсе что они консорциум вендоров?
                              Ну да — они могут продать дизайн готового ядра а могут — лицензию на архитектуру (задорого и ядро дизайнить самим, Apple и Qualcomm пользуется этой опцией, Samsung вроде пользовался но решил что не надо больше).
                                0
                                Скорее тут фактор личности — нужно смотреть, кто это такой смелый экспериментатор в Intel.
                                  –2
                                  Вот я не понимаю, внутри процессоров Intel всё равно используется ARM (их же взломали и получили доступ к внутренней операционной системе MINIX). Кроме того, Qualcomm же выпустила ARM+x86 процессор, где можно на лету аппартаную архитектуру переключать.
                                    +1
                                    >от я не понимаю, внутри процессоров Intel всё равно используется ARM
                                    Вы имели ввиду risc внутри? Там не arm.

                                    >Qualcomm же выпустила ARM+x86 процессор, где можно на лету аппартаную архитектуру переключать.
                                    Нет, там программная эмуляция и не от qualcomm а от microsoft
                                    0
                                    Вот я не понимаю, внутри процессоров Intel всё равно используется ARM (их же взломали и получили доступ к внутренней операционной системе MINIX).
                                    А причём процессоры интела и их же чип ME 11 на платах? )
                                      0
                                      Да кстати, прошивка ME тоже на ARM64. Но это только одно из сотен устройств, которые подключены к чипсету.
                                        0
                                        Да кстати, прошивка ME тоже на ARM64. Но это только одно из сотен устройств, которые подключены к чипсету.
                                        гм, скажите, вы видите разницу между чипами, чипсетами и процессорами интел?
                                          0
                                          Приблизительно. Lakermont CPU — это чипсет. Но полный доступ к декодированному микрокоду и блоку CPU (левый верхний угол, это типо сам кристалл Intel Core и его шина CRBUS) и SSA-PSS подписям (https://twitter.com/h0t_max/status/1263516824211161088?s=20) мы получили типо 3 дня назад. Cмотрите (разумеется там на самом деле намного больше устройств): image
                                          +1
                                          Нет, прошивка ME работала до 2015 года на ARC (не ARM), с 2015 на x86.

                                          Версии ME от 1.x до 5.x использовали ARCTangent-A4 (только 32-битные инструкции), тогда как в версиях от 6.x до 8.x использовался более новый ARCompact (смешанная 32- и 16-битная архитектура набора команд)

                                          Начиная с ME 11, в основе лежит 32-битный x86-совместимый процессор на технологии Intel Quark
                                        0
                                        Во-первых, не Qualcomm, а Nvidia, а во-вторых, не выпустила, а только собиралась, но в итоге отказалась от поддержки x86.
                                        Это если вы про en.wikipedia.org/wiki/Project_Denver
                                          –1
                                          Ну вы бы еще Эльбрусы x86 эмуляцию аппаратную привели в пример. LOL. Надо будет разобраться с snapdragon 8cx.
                                          +1
                                          Если вы про Management Engine (судя по словам про Minix), то

                                          — оно живёт в чипсетах, а не процессорах
                                          — с 2015 года оно крутится на x86
                                          — до 2015 года оно работало на ARC, а не на ARM
                                        0
                                        Подумал о том, что ARM — это консорциум вендоров. А Интел -одна компания, пусть и большая. И решения там принимают люди. Очень умные. Но людям свойственно ошибаться. Поэтому в истории X86 так много было странных решений. Просто эти решения принимались гораздо меньшим числом людей. Иногда вообще одним человеком
                                          0
                                          Почему это ARM — консорциум? Одна компания, намного меньше Intel.
                                            0

                                            Консорциум вендоров. То есть куча компаний, которые применяют ARM в своих чипах.

                                              0
                                              И в чём отличие от Intel?
                                                0
                                                Чипы с архитектурой x86 на настоящий момент производятся только двумя компании в сколь-либо заментном количестве.
                                                  +2
                                                  Отличие в том, что ARM должен согласовывать спецификации с каждым из больших вендоров. И шансов ошибиться у него намного меньше при этом. А Интел не должен ни с кем. И часто решения принимаются одним человеком.
                                                  Я верю в философскую теорему о том, что «только открытые системы могут быть устойчивы». ARM — открытая система. Интел -нет
                                            0

                                            На мой взгляд, little endian гораздо логичнее. Big endian это всего лишь попытка натянуть на АЛУ привычную нам запись чисел слева направо.

                                              +5
                                              Не стоит забывать, что «привычная нам запись чисел слева направо» позаимствована у арабов, которые пишут справа налево, т.е. в естественном порядке от младших разрядов к старшим (little-endian).
                                                0
                                                С чего вы взяли, что она позаимствована от арабов? Арабские цифры на самом деле индийский. Арабы используют другие цифры.
                                                  +1
                                                  Арабы используют другие цифры.

                                                  Как и индийцы ;-)
                                                    +1
                                                    Это вариации начертания, принцип же — позиционный, 10 знаков, младшие справа — одинаков.
                                                    У индийцев, кстати, у каждого языка чуть свои цифры — см. список юникода, например:

                                                    0030;DIGIT ZERO;Nd;0;EN;;0;0;0;N;;;;;
                                                    0660;ARABIC-INDIC DIGIT ZERO;Nd;0;AN;;0;0;0;N;;;;;
                                                    06F0;EXTENDED ARABIC-INDIC DIGIT ZERO;Nd;0;EN;;0;0;0;N;EASTERN ARABIC-INDIC DIGIT ZERO;;;;
                                                    07C0;NKO DIGIT ZERO;Nd;0;R;;0;0;0;N;;;;;
                                                    0966;DEVANAGARI DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
                                                    09E6;BENGALI DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
                                                    0A66;GURMUKHI DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
                                                    0AE6;GUJARATI DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
                                                    0B66;ORIYA DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
                                                    0BE6;TAMIL DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
                                                    0C66;TELUGU DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
                                                    0CE6;KANNADA DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;

                                                    Но важнее то, что у индийцев, которые писали слева направо, позаимствовали арабы, не меняя порядок — младший справа — и затем европейцы, восстановив исходный порядок.
                                                    0
                                                    Не проходит: арабы сами позаимствовали эту запись у индийцев, которые писали слева направо. Европейцы восстановили индийский порядок записи.
                                                    Сам же этот порядок происходит от языка, в котором — за исключением локальных инверсий типа ein zwanzig — во всех мировых языках начинают с самых больших значений (типа «пять миллионов восемьсот тридцать две тысячи...»)
                                                      0
                                                      Как раз в семитских языках исторически были little-endian числительные, например «пять и шестьдесят и триста».
                                                        0
                                                        OK, принимается (хотя ещё надо уточнить типичность этого по всем стилям). Но всё равно европейский порядок цифр — восстановление индийского.
                                                        (Хм, у кого ещё LE порядок в языке?)
                                                        0
                                                        Я ещё добавлю, что основное преимущество арабских/индийских цифр перед традиционными европейскими (римскими, греческими, славянскими и т.д.) — возможность выполнения действий «в столбик».
                                                        Все действия «в столбик» выполняются от младших разрядов к старшим, так что запись справа налево для арабских чисел намного естественнее.

                                                        И ещё, что в древнеанглийском числительные были как в немецком: seofon and twēntiġ; лишь под влиянием понаехавших норманнов англичане перешли на чистый big-endian.
                                                          0
                                                          > Все действия «в столбик» выполняются от младших разрядов к старшим, так что запись справа налево для арабских чисел намного естественнее.

                                                          1. Не все; как минимум деление делается, наоборот, от старших. Это существенно потому, что чем сложнее действие, тем важнее его облегчение — а деление из четырёх арифметических действий безусловно самое сложное.
                                                          2. Логический переход от первой ко второй части мне непонятен. Почему вдруг порядок называния должен соответствовать порядку первых трёх арифметических операций, а не каким-то другим соображениям, вроде того же порядка в устной речи?

                                                          > лишь под влиянием понаехавших норманнов англичане перешли на чистый big-endian.

                                                          Верю. Источники по ОИЕ утверждают тоже такой порядок, типа: «The normal order of composite numerals is units+tens, and there was a natural
                                                          tendency to follow a ‘units+tens+hundreds+...’, cf. Skt. ekādaśaṃ sahasram, lit. ‘one ten thousand’, one thousand and eleven. So e.g. penqe dekṃ kṃtóm, one hundred and fifteen, oinom qatwŕdkṃta septṃkṃtos, seven hundred and forty-one.»
                                                          Но кто сказал, что это хорошо? Язык неолита не очень подходит для современных условий.

                                                            0
                                                            2. Запись числа — это ведь инструмент для прикладных задач; порядок записи не обязан соответствовать порядку чтения (что немецкий и демонстрирует).
                                                              0
                                                              У немецкого это очевидный рудимент, не распространяющийся на более высокие порядки.
                                                                0
                                                                Косвенно распространяющийся («семь-и-двадцать-тысяч»)
                                                            +1

                                                            Капитан, эта прелесть называется позиционная система счисления.

                                                        0
                                                        У каждого из них своя логика.
                                                        Например, одно из обоснований выбора big-endian для протоколов ARPAnet было, что пока младшие байты ползут по каналу, раутер уже может по старшим начинать делать поиск в таблицах.

                                                        Или: если число записывается в переменное число байт — то big-endian дороже для пишущего (надо вначале размотать, найдя, где старшая часть), но дешевле для читающего (просто по порциям читаем и сдвигаем), little-endian — наоборот. Поэтому выбор форматов [u]leb128 для DWARF — ошибка: надо удешевлять читающий отладчик, а не пишущий линкер: линкер работает один раз, а отладчик читает управляющие структуры по многу раз.
                                                          0
                                                          Все арифметические операции делают с меньших разрядов, а большая часть программы это арифметические операции. Так что для читающего лучше читать с младших разрядов.
                                                            +1
                                                            Это имело бы смысл, если бы память читалась и писалась побайтно под управлением процессора. На какой-нибудь S/360 model 20 такое было, да. На Intel 8088 тоже. На первых 68000.
                                                            Но сейчас обычная операция это прочитать/записать строку кэша (32-64-128 байт), дальше с ней целиком работать (между АЛУ, регистрами и кэшами параллельные интерфейсы, иначе тупо скорости не хватит), записать обратно. И там порядок байт конкретной операции с машинным словом уже ничего не значит.
                                                            Длинная арифметика стиля GMP меняла бы стиль, да — грубо говоря, вместо i от 0 до n-1 идём от n-1 до 0. Но там обычно делают LE массив лимбов, даже если лимбы хранятся в BE.
                                                              +1
                                                              Для того чтобы что-то прочитать, сначала надо вычислить адрес: для LЕ ничего делать не нужно, для BE взять размер, сложить с начальным адресом и мы получаем младший разряд. То есть на каждую арифметическую операцию нужно доп.телодвижения.
                                                              ЗЫ Мы тут говорим про длинную арифметику, а если операнды влазят в размер регистра, то там разницы нет, так как чтение все равно за раз будет происходить.
                                                                0
                                                                > Мы тут говорим про длинную арифметику

                                                                Спасибо за уточнение, а то я успел офигеть от первой части. Но давайте тут подробнее. Что вы называете длинной арифметикой и что за «дополнительные телодвижения»?

                                                                Вот я складываю числа (без знака, в стиле GMP mpn — знак отдельно хранится — иначе утонем в ненужных деталях). Для LE это будет выглядеть — считаем, что операнды уже одинакового размера —
                                                                unsigned *param1, *param2, *result;
                                                                ...
                                                                for (int i = 0, carry = 0; i < n; ++i) {
                                                                  carry = ADD(param1[i], param2[i], &result[i], carry);
                                                                }
                                                                


                                                                А для BE цикл превращается в:
                                                                unsigned *param1, *param2, *result;
                                                                ...
                                                                for (int i = n-1, carry = 0; i >=0; --i) {
                                                                  carry = ADD(param1[i], param2[i], &result[i], carry);
                                                                }
                                                                


                                                                Хотя может быть написан и в идиоматичном стиле:

                                                                unsigned *param1, *param2, *result;
                                                                ...
                                                                unsigned i = n, carry = 0;
                                                                while(i--) {
                                                                  carry = ADD(param1[i], param2[i], &result[i], carry);
                                                                }
                                                                


                                                                Тут ADD это что-то типа (тип переноса в общем неважен)
                                                                inline bool ADD(unsigned input1, unsigned input2, unsigned *output, bool carry) {
                                                                  unsigned temp1 = input1 + input2;
                                                                  bool ovf1 = temp1 < input1;
                                                                  unsigned temp2 = temp1 + carry;
                                                                  bool ovf2 = temp2 < temp1;
                                                                  *output = temp2;
                                                                  return ovf1 || ovf2;
                                                                }
                                                                


                                                                Ну и в чём разница между LE и BE, кроме направления итерирования цикла?

                                                                Если же цикла нет — например, процедура просто для чисел двойной длины — и снова пофиг, делать первую выборку по [rcx] или [rcx+8], всё захардкожено…

                                                                Ну в упор не вижу разницы. Покажите код, что ли.
                                                                  +1
                                                                  for(int i=0,…
                                                                  for(int i=n-1,…
                                                                  Переложите их на ассемблерных инструкции. Разница вполне очевидна.А теперь помножьте эти дополнительные операции на на то, как часто это нужно делать (как часто эта функция вызывается)…
                                                                    0
                                                                    > Переложите их на ассемблерных инструкции. Разница вполне очевидна.

                                                                    Да, очевидна: проверка на 0 (случай BE) на какие-то милликопейки дешевле из-за того, что не надо n хранить в регистре. В отличие от вас, я проверил результат реальным ассемблером. Хотите возражать — начните делать это предметно: покажите команды на выходе обоих вариантов и докажите на листинге, что в LE варианте получается дешевле. А то я тут на каждую вашу реплику «разъедающего сомнения» привожу реальный код, а в ответ получаю ещё одно «не верю» без аргументов. Жду.
                                                                  0

                                                                  Достаточно указывать указателем на конец BE числа, чтоб отпала необходимость складывать с размером.

                                                          +2
                                                          Как минимум не надо забывать, что little-endian были PDP-11, VAX, 6502, а также, что многие вещи становятся проще и понятнее в little-endian… например, читая доку по z/Arch надо следить, каким образом мы рассматриваем конкретный регистр: одни и те же биты будут называться 0-31 (0 — старший), если регистр рассматривается как 32-битный, и 32-63, если как 64-битный. На little-endian такого нет, расширение возникает естественно без перенумерации.

                                                          А если ещё вспомнить, что знаменитая IEN 137, в которой были впервые введены термины little-endian и big-endian, выпущена в 1980, а x86 появилась в реально массовом употреблении на несколько лет позже… увы, Intel виноваты только в одном — что их архитектура оказалась ещё одной сверхуспешной.
                                                            0

                                                            Нумерация битов в слове не имеет никакого отношения к порядку байт того же слова в памяти. И что в ibm360 и всех последующих, а также в powerpc нумерация битов со старшего разряда — это конечно дремучий трындец.

                                                              0
                                                              > Нумерация битов в слове не имеет никакого отношения к порядку байт того же слова в памяти.

                                                              То есть вы IEN137 тоже не читали? Ну-ну.

                                                              Вот пусть у нас массив битовых флагов. Мы с ним можем обращаться, например, так:

                                                              typedef uint8_t access_t;
                                                              const unsigned shift_for_cell = 3;
                                                              const unsigned val_mask = 7;
                                                              _Bool get_bit(void *bitset_area, unsigned index) {
                                                                unsigned offset = index >> shift_for_cell;
                                                                unsigned shift = index & val_mask;
                                                                return 0 != (1 & (((access_t*) bitset_area)[offset] >> shift));
                                                              }
                                                              


                                                              Что будет, если мы изменим access_t с uint8_t на uint32_t, shift_cell на 5, а val_mask на 31? Ну вот решили, что удобнее доступаться не по 1, а по 4 байта?
                                                              Для little endian результат не изменится. Для big endian — будет читаться совсем другое: порядок доступа поменялся.

                                                              Как исправить, чтобы порядок не менялся от размера access_t на big endian? Проще всего в вычислении shift заменить index на ~index. Но при этом бит 0 будет старшим в байте по смещению 0, а не в младшем.

                                                              Представим себе структуру с битовыми полями. Например, сделаем её такой (чтобы поактуальнее):

                                                              struct float32 {
                                                                unsigned sign: 1;
                                                                unsigned exponent: 8;
                                                                unsigned significand: 23;
                                                              };
                                                              


                                                              Почитаем одно поле:

                                                              unsigned get_sign(const float32 *val) {
                                                                return val->sign;
                                                              }
                                                              


                                                              Сначала для s390x:

                                                              get_sign:
                                                              l %r2,0(%r2)
                                                              risbg %r2,%r2,64-1,128+63,64+32+1
                                                              br %r14


                                                              тут всё правильно — сдвинули вход на 1 бит влево по кругу (старший бит стал младшим), отделили один этот бит на выход и вернули.

                                                              Теперь пробуем на AA64:

                                                              get_sign:
                                                              ldrb w0, [x0]
                                                              and w0, w0, 1
                                                              ret


                                                              Ой, что случилось? Почему оно взяло младший бит вместо старшего? Глупый, глупый GCC? Не знает, что надо было старший бит брать? Меняем определение:

                                                              struct float32 {
                                                                unsigned significand: 23;
                                                                unsigned exponent: 8;
                                                                unsigned sign: 1;
                                                              };
                                                              


                                                              Смотрим:

                                                              get_sign:
                                                              ldrb w0, [x0, 3]
                                                              ubfx x0, x0, 7, 1
                                                              ret


                                                              Ух ты — заработало!

                                                              Как вы думаете, почему GCC для LE заполняет поля начиная с младших бит, а для BE — со старших?

                                                              > И что в ibm360 и всех последующих, а также в powerpc нумерация битов со старшего разряда — это конечно дремучий трындец.

                                                              Это не «дремучий трындец», а естественное следствие big endianness.

                                                              Можно пойти против него, но начнутся разрывы в неожиданных местах.
                                                        +1

                                                        У меня, кстати, лежит плата под iAPX 432. Может дойдут руки пощупать этот процессор в живую.

                                                          0
                                                          Может все же не стоит оживлять призраков? Мало ли… :)
                                                            0
                                                            Может не надо оживлять призраков. Мало ли… :)
                                                        +8
                                                        У Интел было как минимум три возможности перелопатить набор инструкций — при переходе в защищеный режим (286) и при смене разрядности (32 и 64). Все равно для декодирования используется режим процессора/дескрипторы. Но с 64 я смутно помню, что Интел как раз и хотела все перелопатить, но тут подсуетилась амд выпустив быстрее набор инструкций для 64 разрядности.
                                                          +2
                                                          Да. Был такой момент. EM64T назывался. Когда Intel на своем поле оказался в роли догоняющего.
                                                            0
                                                            Но с 64 я смутно помню, что Интел как раз и хотела все перелопатить

                                                            Пробовали до этого, когда IA64 делали с возможностью исполнения IA32-кода в аппаратной песочнице. Получилось «не очень».
                                                              +2
                                                                0

                                                                Комментарий не прогрузился что ли?

                                                                  0
                                                                  Похоже на то :( Кажется я там писал, что не очень -это еще очень мягко сказано. Работал этот блок медленно а энергии потреблял больше чем все осталное
                                                                +1
                                                                Так они эту песочницу сделали очень слабой в расчёте, что народ побежит на IA64. Сделали бы нормальной — AMD не опередила бы тут.
                                                                Какое-то странное у них соревнование — Intel уносится в выси из слоновой кости, AMD ищет явные провалы и затыкает их…
                                                              +13
                                                              Напомните, пожалуйста, какая архитектура способна выдавать высокую производительность в однопотоке, а какая сейчас по сути не может похвастаться ничем, кроме количества ядер и техпроцесса.
                                                              Грубо говоря, при равном размере кэшей, количество промахов будет тем больше, чем больше длина инструкции.
                                                              Только вот чем проще ISA — тем больше инструкций содержит код. Длинные инструкции CISC в RISC превратятся не в короткие инструкции, а в огромное количество коротких инструкций. И мне почему-то кажется, что код на хорошо спроектированной CISC ISA окажется короче, чем на RISC.
                                                                +4
                                                                Чем меньше кода для преобразования инструкции в микрокод тем лучше. Всякие конвейеры выборки и другая муть не от хорошей жизни придумана а чтобы нагрузить по полной все блоки процессора.
                                                                  +2
                                                                  Ну так загрузили же блоки процессора — в чем же тогда проблема? Декодер работает асинхронно и на большой дистанции не добавляет задержки. Говорят, правда, что в него можно упереться — но у меня вот не получалось, насколько я помню.
                                                                    0
                                                                    По большому счету это так. Обычно проблемы front end связаны или с предсказанием ветвленией или с промахами в instruction cache. Проблемы с декодером — экзотика. Хотя если еще увеличивать длину командного слова — она может стать реальностью.
                                                                  0
                                                                  Только вот чем проще ISA — тем больше инструкций содержит код. Длинные инструкции CISC в RISC превратятся не в короткие инструкции, а в огромное количество коротких инструкций. И мне почему-то кажется, что код на хорошо спроектированной CISC ISA окажется короче, чем на RISC..
                                                                  Это отчасти справедливое замечание. Но тут я бы хотел послушать компайлерных людей, ибо самому тяжело сравнивать. Чисто теоретически CISC может иметь преимущество, когда ставит в соответствие более частым инструкциям или последовательностям более короткие коды (Huffman, arithmetic). Но проблема будет в том, что это будут команды переменной длины и декодировать их можно будет только последовательно.
                                                                    +2
                                                                    Проблема большого количества инструкций только одна — возможность загрузить их в процессор — а это доступ к памяти. С другой стороны если посмотреть на код, то в большинстве случаев там все равно нет длинных кусков, а всегда есть какие-то переходы/вызовы процедур. А это значит что все равно нужно прервать монотонное выполнение инструкций.
                                                                      0
                                                                      Чем плотнее код (грубо говоря, чем больше инструкций на килобайт), тем эффективнее используется instruction cache, а это уже сильно вляет на производительность.
                                                                      +2
                                                                      Думаю, задизайнить ISA так, что бы длина инструкции декодировалась практически мгновенно — не проблема.
                                                                        0
                                                                        Не уверен. Мне в детстве пришлось повозиться с декодированием битстримов по хаффмановским табличкам. Это сугубо последовательная операция. А при добавлении каких то маркеров появляется избыточность.
                                                                        +6

                                                                        Как минимум Таненбаум писал, что современные компиляторы используют CISC-процессоры фактически как RISC, генерируют только простейшие инструкции. Мои личные наблюдения это подтверждают: и gcc, и llvm для x86 и для ARM генерируют очень похожий код. Из сложного используется только SIMD.

                                                                          +1
                                                                          Это не потому, что компиляторы не способны генерировать сложные инструкции, а потому, что современные процессоры их выполняют медленее, чем простые.
                                                                            +2

                                                                            Ну так современные процессоры все равно раздраконивают CISC-команды на RISC-составляющие, поэтому и нет принципиальной разницы.

                                                                            +1
                                                                            Проверять утверждение про CISC-процессоры на основе ARM — это сильно :)

                                                                            Но Таненбаум прав в том, что как минимум GCC и LLVM они строго SSA-based. Это резко упрощает оптимизацию верхнего уровня, но приводит к тому, что модифицирующие операции, которые являются основной вкусностью CISC для кодера-человека, теряют смысл (совпадение ячейки аргумента и результата надо ещё явно обеспечить), хитрые комбинированные адресации типа @-(Rn) надо явно собирать обратно из возможно разбежавшихся по коду операций… в итоге получается, что переводить результат после оптимизаций SSA в RISC в десятки раз легче, чем в CISC. Если не будет найдено новых моделей работы компилятора, или хотя бы эффективной свёртки после SSA в CISC-операции — то причин строить новые CISC не будет, от слова «совсем».
                                                                            (Проблемы кэширования и out-of-band исполнения тут, конечно, играют тоже существенную роль. Но сейчас я не о них.)
                                                                            0
                                                                            Чисто теоретически CISC может иметь преимущество, когда ставит в соответствие более частым инструкциям или последовательностям более короткие коды (Huffman, arithmetic). Но проблема будет в том, что это будут команды переменной длины и декодировать их можно будет только последовательно.

                                                                            Можно собрать лучшее от обоих миров: так, в Thumb-2 команды переменной длины (16 либо 32 бит), но это всё равно RISC ISA, специально оптимизированная под плотность кода. И поскольку длина команды однозначно определяется по старшим битам, то их несложно декодировать параллельно.
                                                                              +2
                                                                              В 64-битке ARM этого не делает (пока?)
                                                                              А вот RISC-V ввели compressed set и за счёт этого уже выигрывают по длине кода перед x86.
                                                                              0
                                                                              Думаю проблема не в CISC, RISC или конкретной ISA, а в недостаточной степени абстракции решаемой задачи от процессора. В целом любая система команд, любой процессор после некоторого времени активной «жизни» обрастет большим числом проблем. Процессор (и не только эта часть вычислительной системы), как живое существо накапливает ошибки, которые приведут его к смерти. На сегодня нет механизма «перерождения» вычислительной системы, кроме как переписывать ПО (пусть даже не 100%) с использованием человека.
                                                                              PS Да и сам человек (программист) в процессе написания ПО вынужден думать как процессор, а это существенно ограничивает его возможности.
                                                                              Аналогия программирования: Написание инструкций быстрому, точному, исполнительному но все же «дураку».
                                                                                0
                                                                                нет механизма «перерождения» вычислительной системы, кроме как переписывать ПО (пусть даже не 100%) с использованием человека.
                                                                                На моей памяти таких моментов было несколько. SIMD, многоядерность. И да — каждый из них требовал серьезного перелопачивания всей экосистемы. Ну по крайней мере перекомпиляции. Но каждая такая революция была «бархатной». Происходила постепенно и требовала много времени…
                                                                                  0
                                                                                  SIMD — без переписывания алгоритма? Скорее всего переписали системные библиотеки?
                                                                                  По поводу многоядерности, тут совсем печально, современная вычислительная парадигма (Фон Нейман) не содержит в себе не то что понятия многоядерности, так в ней вообще нет такой сущности как другая точка исполнения команд и изменения данных (поток команд и тд). Соответственно нет никаких механизмов кооперации, синхронизации и распределения решаемой задачи. Наличие одной точки исполнения вообще убило прогресс производительности (в идеале производительность должна линейно зависеть от числа транзисторов).
                                                                                  То что необходимо получить (принципы создания ПО), должно иметь свойство жидкости, заливаемая в любой сосуд принимает его форму. А сейчас мало того что не изменяет форму, так еще и при переносе тащит за собой и часть особенностей предыдущей вычислительной системы.
                                                                              +3
                                                                              код на хорошо спроектированной CISC ISA окажется короче, чем на RISC

                                                                              Проблема в том, что семейство x86 имеет плохо спроектированный ISA.


                                                                              Только вот чем проще ISA — тем больше инструкций содержит код.

                                                                              На ARMv7 и ARMv8 количество инструкций сравнимо с x86-64 при более простом ISA. По крайней мере это верно для первого попавшегося примера: https://godbolt.org/z/_m4EBC

                                                                                0
                                                                                Проблема в том, что семейство x86 имеет плохо спроектированный ISA.
                                                                                Почему?
                                                                                На ARMv7 и ARMv8
                                                                                ARM вообще-то уже давно свернула с RISC-дорожки.
                                                                                  +2
                                                                                  А если считать не в количестве инструкций, а в байтах?
                                                                                  Если не искусственные примеры, то я как-то развлёкся с компиляцией реальной программы (прокси особого сетевого протокола):

                                                                                  -rwxrwxr-x 1 netch netch 344456 лис 24 21:19 qmodo_aa64_s
                                                                                  -rwxrwxr-x 1 netch netch 340376 лис 24 21:10 qmodo_amd64_s
                                                                                  -rwxrwxr-x 1 netch netch 531552 лис 24 21:25 qmodo_mips64_s
                                                                                  -rwxrwxr-x 1 netch netch 466088 лис 24 21:17 qmodo_ppc64_s
                                                                                  -rwxrwxr-x 1 netch netch 355752 лис 26 14:43 qmodo_rv_s
                                                                                  -rwxrwxr-x 1 netch netch 408640 лис 24 21:11 qmodo_s390x_s
                                                                                  -rwxrwxr-x 1 netch netch 336776 лис 24 21:35 qmodo_sparc64_s
                                                                                  


                                                                                  RISC-V тут чуть длиннее, но незаметно; и это ещё без compressed команд, которые укорачивают ещё процентов на 20. Неожиданно Sparc опередил на процент:). ARM/64 (aa64) больше аж на 1%. Самый дикий провал у MIPS, неожиданно. Опции сборки одинаковые (-O, strip), везде gcc5, кроме RISC-V с gcc6. s390 жалко: из-за совместимости они вынуждены большинство полезных команд делать 6-байтными, и то нарастание не очень заметное.
                                                                                    0
                                                                                    В менее синтетическом примере 32-битный mips оказался самым компактным.
                                                                                      0
                                                                                      1. У меня был пример никак не синтетический, а реальная программа, так что «менее синтетический» тут как-то некорректно. C++11 без тяжёлой шаблонизации, простой иерархией типов и т.п.
                                                                                      Tcpdump тут более сомнительный — глубоко системная программа со специфическими оптимизациями.

                                                                                      Можно сейчас на чём-то повторить, но надо, чтобы оно просто компилировалось (без кучи библиотек), иначе у меня не хватит терпения.

                                                                                      2. Вы про 32-битный. Даже если это было так, они это преимущество сейчас теряют (кроме embedded).
                                                                                  +1
                                                                                  Чем мощнее система команд, тем выше производительность в сложных вычислениях за счёт меньшего количества тактов на решение задачи, но и выше энергопотребление. Что сейчас видно на примере x86 (x64) vs ARM. ARM при своей многоядерности и тех же 2...3 ГГц до сих пор не смогли проникнуть на рынок ПК (кроме маломощных компьютеров), но при этом ARM захватил рынок носимых устройств с батарейным питанием.
                                                                                    +3
                                                                                    >Напомните, пожалуйста, какая архитектура способна выдавать высокую производительность в однопотоке
                                                                                    Power9?
                                                                                    >а какая сейчас по сути не может похвастаться ничем, кроме количества ядер и техпроцесса.
                                                                                    ShenWei? хотя может вы и MIPS имели в виду, а может и мультиклет какой.
                                                                                      0
                                                                                      а в огромное количество коротких инструкций.

                                                                                      «Огромное» количество это сколько?
                                                                                      Что бы не измерять сферических коней в вакууме, давайте на реальных примерах.
                                                                                      Так вот в реальности ARM часто нужно меньше «коротких» RISC инструкций чем х86 «длинных» CISC инструкций.
                                                                                        +1
                                                                                        ARM давно уже CISC.
                                                                                        Вы, кстати, правильно сделали, что взяли «коротких» в кавычки — в ARM длина инструкции не может быть меньше 4 байт, тогда как в x86 — может.
                                                                                          +1
                                                                                          ARM это не CISC. Это скорее Advanced RISC (что отражено в названии фирмы).
                                                                                          Дело в том, что разработчики архитектуры прагматично подходили к вопросу организации ISA, а не идеологически. Поэтому там были сделаны вещи, нужные здесь и сейчас (т.е. в 80х годах). Вещи, которые плохо ложились на OoO (например conditional execution, LDM/STM). Поэтому архитектура была перепроектирована «с чистого листа» и ARMv8 стал ещё более классическим RISC чем ARMv7.

                                                                                          в ARM длина инструкции не может быть меньше 4 байт, тогда как в x86 — может.

                                                                                          Вообще-то может. Thumb — фиксированная длина 16-бит, Thumb2 — 16+32-бит VLE. Jazellе — 8 бит байткод.
                                                                                          Но это не какие-то особенные инструкции, а просто режим компрессии — для каждой компактной версии есть аналог в полном наборе. Опять же это не делает ARM CISC-ом.
                                                                                          В ARMv8 опять вернулись к фиксированной длина команды, что есть один из признаков классической RISC архитектуры (как я уже говорил).
                                                                                          Что характерно, даже имея фиксированную длину инструкции — 32 бит, плотность кода у ARMv8 выше чем у x86_64.
                                                                                            0

                                                                                            тут интересный вопрос, что именно делает ARM — RISC'ом. если его называть load/store архитектурой — то всё верно. а c очень уж расплывчатым понятием "RISC" как быть?

                                                                                              +1
                                                                                              Согласен. RISC и CISC — это не четко определенные термины. Скорее «понятия» :)
                                                                                                0
                                                                                                Сами термины не имеют чёткого описания, скорее это набор признаков, по которым мы можем их расположить на оси CISC-RISC.
                                                                                                Одним из таких признаков которых является наличие сложных команд. Сложные они не потому что делают несколько операций, а задействуют несколько блоков верхнего уровня (MEM, ALU) (*1) или требуют микропрограмму.

                                                                                                Load-op/RMW команды обычно являются примером таких операций.
                                                                                                Но так как не бывает правил без исключений, в ARM есть и те, и другие.
                                                                                                VLDx, где x=1..4 напоминает load-op, выполняет загрузку и вставку лейнов в несколько регистров. Правда ALU тут не используется и не нарушает правила (1).
                                                                                                infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489h/CIHCCEBB.html

                                                                                                SWP — RMW операция обмена регистра с памятью
                                                                                                infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/Chdbbbai.html
                                                                                                Эта операция считается deprecated, но она есть.

                                                                                                х86 точно так же не является «абсолютным» CISC.
                                                                                                Он не поддерживает ни операции mem->mem, ни сложные режимы адресации,
                                                                                                как умеет 68020.
                                                                                                  +2
                                                                                                  операции mem->mem
                                                                                                  push dword ptr [eax]
                                                                                                    0
                                                                                                    Да даже и MOVS[BWDQ].
                                                                                                    Но это отдельные инструкции, а не все, как в PDP-11.
                                                                                                      0

                                                                                                      Можно даже так:


                                                                                                      push dword ptr [eax + ebx*4 + 16]
                                                                                                0

                                                                                                в 32-битном режиме с THUMB-2 — длина инструкций 2 или 4 байта.

                                                                                              +1
                                                                                              Напомните, пожалуйста, какая архитектура способна выдавать высокую производительность в однопотоке, а какая сейчас по сути не может похвастаться ничем, кроме количества ядер и техпроцесса.
                                                                                              Хм… x86 от АМД в обе ветки? )
                                                                                                0
                                                                                                И x86 и ARM (Apple) показывают высокую производительность однопотока. ISA — это только фасад процессора, все самое интересное внутри.
                                                                                                  +1
                                                                                                  Когда фасад занимает 10% чипа (и, вероятно, потребляет 10% электричества) — это уже серьёзно.
                                                                                                    0
                                                                                                    Согласен. Ходит спорное утверждение, что ARM — это медленно.
                                                                                                  0
                                                                                                  > И мне почему-то кажется, что код на хорошо спроектированной CISC ISA окажется короче, чем на RISC.

                                                                                                  Самый короткий код сейчас из основных ISA на RISC-V с поддержкой compressed набора. Основной набор у них, как у большинства RISC, из 4-байтовых команд, но они тщательно разобрали реальные шаблоны и зафиксировали их в «сжатом» наборе.
                                                                                                  Несжатый у них, у AArch64 — немного длиннее x86.

                                                                                                  > Только вот чем проще ISA — тем больше инструкций содержит код.

                                                                                                  Так RISC/CISC это не о простоте набора, а о простоте базовой логики одной инструкции. При этом конкретная выполняемая операция может быть нетривиальной, как, например, BFM из ARM.

                                                                                                  > Напомните, пожалуйста, какая архитектура способна выдавать высокую производительность в однопотоке

                                                                                                  На сейчас это на 100% следствие того, что Intel успел раньше и стал толще. ARM догоняет, но за счёт сокращения подобных утяжелений у него шансы выше.
                                                                                                  +2
                                                                                                  Самый красивый набор инструкций был у pdp-11. И его режимы адресации тоже сказка.
                                                                                                    0
                                                                                                    15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
                                                                                                    B Opcode Mode R Src Mode R Dst

                                                                                                    нашел в википедии. Ну да — логика за этим есть. Но как расширять набор команд?
                                                                                                      0
                                                                                                      Ну кто в те времена думал о расширении команд? Тогда новый процессор — новая архитектура. Для 32 разрядной архитектуры он стал VAX-11.
                                                                                                      ЗЫ Хотя оригинальный pdp-11 и расширяли — добавили команды умножения/деления, вещественные числа…
                                                                                                        0
                                                                                                        Вот в том то и дело. Хороший дизайн ISA должен закладывать возможности расширения с самого начала. только вот осознали этот очевидный в общем то факт уже в конце 80'х…
                                                                                                        0
                                                                                                        Расширять его как раз банально, было бы зачем. В основном наборе много неиспользуемых опкодов (10-77, часть 7000-7777, 75000-76777...) Сделать каждый из них префиксом для следующего 16-битного слова со своими командами — «и телемаркет» ©.
                                                                                                        Другой вопрос, что архитектура тупо перестала быть интересной с новыми ресурсами.
                                                                                                      +4
                                                                                                      Все это очень логично, вот только x86 со своим ужасающим набором инструкций работает на 4,5ГГц, а ARM на 3. Хотя технологические возможности Intel и того же TSMC весьма близки.
                                                                                                        +8

                                                                                                        О, кстати. Надо будет как нибудь в следующий раз написать про частоту, длину пайплайна и энергопотребление. Это моя любимая тема. Я ещё помню p4, который работал на 10ГГц и охлаждался жидким азотом :)

                                                                                                          0
                                                                                                          Уже ждем!
                                                                                                          +8
                                                                                                          Только x86 это дескоп/сервер и ему можно жрать энергии сколько хочешь — главное производительность, а arm это мобильные устройства и там прожорливость очень не приветствуется. Только недавно начали пытаться arm продвигать в серверные платформы — посмотрим что получится.
                                                                                                            +5
                                                                                                            Да как недавно — лет пять-шесть уже об этом слышу.
                                                                                                              +1

                                                                                                              Насколько я помню спецификации SVE датируется 2017-2018 годом. Ну то есть можно сказать что именно в этот момент arm стал серьёзно заглядывать на ентерпрайс рынок

                                                                                                                +1

                                                                                                                Вообще лет 10 уже.


                                                                                                                Ветку ARM8 х64, при анонсе разработки в 2011 году позиционировали не больше не меньше, как убийцу блэйд-серверов на х86 архитектуре.
                                                                                                                В 2015 или 2016 году, вроде, эти самые серверы таки были выпущены, но что то пошло не так :)

                                                                                                                  +1
                                                                                                                  Ну деклараций о намерениях в этом мире всегда хватало… Я то имел в виду, что более или менее реальная жизнь началась, когда ARM взялся за SVE. Имея на вооружении только 128 bit SIMD (NEON) на этом рынка кокнурировать сложно…
                                                                                                                    +1
                                                                                                                    У ThunderX3 4 юнита NEON, т.е. 512 бит суммарно, что даёт 3.3TFLOPS в теории, как и у A64FX.
                                                                                                                    Для серверов же общего назначения широкий SIMD и не нужен.

                                                                                                                    kingleonfromafrica
                                                                                                                    ARM серверы в 2015 и в 2020 это две большие разницы.
                                                                                                                    Тогда не была готова софтверная инфраструктура. Особенно это касалось загрузки, сборки ОС, работы популярных приложений. Лишь недавно стало возможным пользоваться ARM серверами точно так же как и x86, что видно на примере Graviton2. Сейчас можно скачать образ ОС и запустить его на своей ARM системе, без того, чтобы проверять, есть ли поддержка именно вашей платы.
                                                                                                                      +1

                                                                                                                      Это всё понятно, но где же тесты сопоставимых по цене/количеству процессоров/цвету корпуса/etc. конфигураций и обзоры их результатов?
                                                                                                                      Их нет.
                                                                                                                      Меня это очень удивляет, если что.
                                                                                                                      Я бы и сам хотел получить сервер с сопоставимой х86 производительностью, но не требующий двух блоков питания с мощностью как у сварочного аппарата ...


                                                                                                                      Ну, и да, вопрос тротлинга на х86 тоже весьма не приятная вещь — покупая сервер планируешь, что он будет "топить на все деньги", а в реале это всё как то не совсем так получается.
                                                                                                                      Это конечно вопрос к инженерам, протупившим при реализации системы охлаждения, но это вполне себе повседневная проблема.


                                                                                                                      Но, реальных решений на ARM как не было, так и нет.

                                                                                                                        +1
                                                                                                                        Это всё понятно, но где же тесты сопоставимых по цене/количеству процессоров/цвету корпуса/etc. конфигураций и обзоры их результатов?

                                                                                                                        Проблема курицы и яйца. Вы требуете обзор каких-то интересных вам железок, но чтобы они были, ARM серверы должны приносить ощутимую прибыль, чего мы не наблюдаем пока. Думаете по щучьему велению, по вашему хотению появится куча компаний и 100500 моделей серверов?
                                                                                                                        Сейчас мы находимся в самом зарождении рыночной ниши.
                                                                                                                        Время покажет насколько она жизнеспособна.
                                                                                                                        Только гиперскейлы сейчас могут позволить себе экономить на ARM серверах. А для штучной продажи в магазине ARM серверы будут дороже х86.
                                                                                                                        store.avantek.co.uk/arm-servers.html

                                                                                                                        Тестов, на самом деле полно. По Graviton 2, A64FX, ThunderX2 есть масса информации.
                                                                                                                        Последние два используются для суперкомпьютеров Fugaku, Isambard, Astra.

                                                                                                                        Вот недавно появился обзор ARM-сервера Huawei более близкого к потребностям обычных людей.
                                                                                                                        servernews.ru/1010630
                                                                                                                        Тесты это хорошо, но измерять нужно свои нагрузки а не обстрактные 7z в вакууме. Делаете инстанс на Graviton2 и вперёд.

                                                                                                                        Но, реальных решений на ARM как не было, так и нет.

                                                                                                                        Ну нет, так нет. Я не продажник, а любитель поразбирать микроархитектуры =)
                                                                                                                        Уже есть 3 работающих суперкомпьютера на ARM, а будет ещё больше.
                                                                                                                        Cloud — сервисов на ARM тоже несколько есть. Серверы и СХД на ARM тоже можно купить.
                                                                                                                          0
                                                                                                                          arm.com хостится на ARM-серверах, хотя скорее в маркетинговых целях, чем ради экономии на электричестве.
                                                                                                                            0

                                                                                                                            Пример с обзором и тестированием ARM-сервера Huawei очень показателен тем, что ни каких ровно преимуществ у него нет.
                                                                                                                            При сопоставимой производительности вполне себе сопоставимая потребляемая мощность.
                                                                                                                            Это близко не обещанные х10 экономии — там о какой либо заметной разнице вообще речь не идет.


                                                                                                                            Тестирование, замете, выполнено "на поле" ARM. Тестировалось и сравнивалось только то, что на нем вообще запустилось.
                                                                                                                            Я не хочу тут как то особо ехидничать и понимаю, что проблема "курицы и яйца" имеет место быть, но первое, что мне пришло в голову, это слова представителей Intel про P4 — "это не процессор плохой, это вы программы не правильные под него пишете" на какой то конференции в Москве примерно в 2003 году :)

                                                                                                                            0
                                                                                                                            Ждите MacBook на ARM в 2020-м. Там и сравнят.
                                                                                                                            0
                                                                                                                            Я вижу кроме меня только вы не опускаете ARM в каждом комменте.
                                                                                                                            Решил с вами поделиться новостью.
                                                                                                                            Май настал)
                                                                                                                            www.anandtech.com/show/15813/arm-cortex-a78-cortex-x1-cpu-ip-diverging/4
                                                                                                                              0
                                                                                                                              Спасибо. Добавил в закладки себе
                                                                                                                      0

                                                                                                                      Нет, тоже не сколько хочешь. Если бы это так было — не было бы троттлинга. А они троттлятся тока в путь. Power envelopes никто не отменял для серверов. Но там они связаны скорее с отводом тепла.

                                                                                                                        +1
                                                                                                                        Продвигали уже и раньше, да так, что Qualcomm отказался от сей затеи, вот старый бенчмарк: blog.cloudflare.com/arm-takes-wing
                                                                                                                        Хотя, ЕМНИП, Amazon как раз на ARM дизайнит свои новые процессоры.
                                                                                                                          0
                                                                                                                          Посмотрел бенчмарки — интересно, спасибо. Потом гляну повнимательнее еще. Первое впечатление — там где требуются длинные SIMD ARM конечно проигрывает. А в остальном — вполне себе ничего
                                                                                                                          0

                                                                                                                          Так и для серверов прожоривость тоже не приветствуется. Собственно, поэтому х86 процессоры в топовых серверах тоже редко работают на частотах выше 3 ГГц.

                                                                                                                            0
                                                                                                                            Ага. Это хороший пойнт. Google, Amazon и Facebook — никогда не берут топ бины(в отличие от HPC). Они берут системы на 2-3 ступеньки ниже по частоте. Потому что в их прилагах много задержек из за памяти, сетки и тп. И они не хотят платить за циклы, которые процессор намолотит ожидая данные
                                                                                                                          0
                                                                                                                          Только инструкции x86 выполняются за 2-3 такта, а ARM — за 1, если не ошибаюсь
                                                                                                                            +1
                                                                                                                            инструкции x86 выполняются за 2-3 такта

                                                                                                                            Не совсем так.
                                                                                                                            Мнемоника — это команды которые считывает процессор из памяти, то что мы можем контролировать глазами через экран монитора.
                                                                                                                            В арм одна машинная мнемоника имеет от одной до семи отдельных инструкций. Каждая инструкция выполняется синхронно с другими, имеет задержку выполнения от двух до четырнадцати тактов. Задержка потока и физическое исполнение — разные вещи. Читать можно быстрее чем будет фиксироваться физическое исполнение — получается 1 такт. Всё ломается с кодами ветвления.
                                                                                                                            В х86 одна мнемоника может иметь в своём составе сотни инструкций. Всё точно так-же использует конвейер. Та-же задержка, но теперь на каждую инструкцию отдельно. Идеальный код без ветвлений даёт выполнение одной мнемоники за такт. Но первое-же условие перехода — отбрасывает х86 в пещерный век.
                                                                                                                            Вся разница в энергопотреблении, и в условиях подсчёта.
                                                                                                                            Для интела удобно считать скорость через инструкции, потому как всегда получается больше чем у арм.
                                                                                                                            А для арм удобнее считать через мипс, где интел в глубокой жопе.
                                                                                                                              +5
                                                                                                                              AVI-crak
                                                                                                                              Для Интел МИПСы не имеют большого значения, т.к. те же AVX512, за счёт своей 512-битности, положат на лопатки любой АРМ с его МИПСами. Интел пошёл другой дорогой — добавляя пакеты инструкций для решения задачи минимальным количеством инструкций, классический процессор эту задачу будет решать десятками-сотнями низкоуровневых инструкций. Выигрывая в МИПСах, но проигрывая в скорости решения задачи. Умножая 256 на 256 бит, Интелу потребуется только одна инструкция, причём все операнды лягут в регистры, а АРМ будет умножать столбиком по 32 на 32 бита с суммированием и сохранением в ОЗУ кэша, т.к. ему даже регистров не хватит для этих 128 байт множителей и результата…
                                                                                                                                –1
                                                                                                                                nixtonixto
                                                                                                                                Проверь: две операции умножения AVX512, и после команда ветвления по сравнению результата. Время выполнения должно охладить веру в x86.
                                                                                                                                Код обязательно в асме вставке, иначе gcc наоптимизирует предварительное вычисление.
                                                                                                                                  0
                                                                                                                                  AVI-crak
                                                                                                                                  Такие операции используются в сложных расчётах типа шифрования с длинным ключом, вычислений с повышенной точностью, там очень много математики и очень мало переходов. Сам процессор всё так же 64-битный, нет и речи по переводу процессора на 512 бит, поэтому ветвление не пострадало. И компилятор, естественно, нужно использовать знакомый с этим набором инструкций, иначе он действительно наоптимизирует.
                                                                                                                                  +1
                                                                                                                                  AVX512 чудовищно дорог по энергии. На самом деле, даже AVX256 уже дорог — если он не используется, блок с ним тупо обесточивают.
                                                                                                                                  ARM тут, кстати, поступил умнее — сделал блок, которому можно просто задавать любую размерность, которую осилит на практике — так что код не надо переписывать, если следующий процессор станет поддерживать 512 бит вместо 128.

                                                                                                                                  Новые наборы у Intel для конкретных применений, типа видеокодеков — да, факт, начиная с BMI наборов. Но вы ошибаетесь, отрицая это у ARM: ARM это делает вместе с конкретными вендорами и не вынося на общий доступ, поэтому в публичную документацию это обычно не попадает. Какое-нибудь «Умножая 256 на 256 бит» делается внутри Qualcomm или Apple, и доступно под NDA авторам конкретной библиотеки.

                                                                                                                                    0
                                                                                                                                    Кастомизация процессора под заказчика — страшно дорогая. На рынке смартфонов с миллионными продажами это ещё можно позволить, особенно учитывая fabless статус ARM, но как вы себе представляете кастомизировать процессор под требования конкретного ПО? Наряду с Nvidia Quadro будут ещё и линейки процессоров с определёнными вычислительными блоками? Под видеомонтаж свой, под 3D свой?

                                                                                                                                    Нереально это, поэтому Intel добавляет только универсальные наборы инструкций.
                                                                                                                                      +1
                                                                                                                                      > Нереально это, поэтому Intel добавляет только универсальные наборы инструкций.

                                                                                                                                      Что вы имеете в виду тут под «универсальными» наборами?
                                                                                                                                      Вот смотрю список таких специфических команд Intel:

                                                                                                                                      BEXTR, BLSI… — нужны под конкретные видеокодеки. Завтра или лет через 10 кодеки поменяются, команды станут не нужны.
                                                                                                                                      AES*: ну ладно, AES уже 20 лет как жив и пока не взломали. Но вокруг полно альтернативных шифров. Почему какие-нибудь ChaCha не получили такой привилегии? Только за отсутствие госстандарта?
                                                                                                                                      SHA1*: а вот этот уже устарел, есть подозрения на успешные атаки типа second preimage. Да и SHA256 хоть и активный набор — но SHA-3 уже принят.
                                                                                                                                      CRC32: реализует Castagnoli. Верю, кому-то она нужна. Но это, например, не CRC-32-CCITT, которая в Ethernet — значит, соответствующие возможности аппаратно недоступны. Где используется Castagnoli? iSCSI, SCTP и пара линуксовых файлух? Из этого набора только iSCSI заслужил бы отдельной команды у Intel.
                                                                                                                                      GF2P8AFFINEQB: ещё криптография. Напомнить, что из технологий 1990-х нам остался разве что RSA, и тот всем подозрителен?
                                                                                                                                      ADCX, RORX...: ещё вылизывание под конкретный кодек.

                                                                                                                                      Извините, сказка про "только универсальные наборы" как-то рассыпается.

                                                                                                                                      > но как вы себе представляете кастомизировать процессор под требования конкретного ПО?

                                                                                                                                      Ну вот потому я и говорю про вендоров. Для них встроить свой блог даже в Verilog-представление — не фатальная проблема.
                                                                                                                                        0
                                                                                                                                        По идее подобные алгоритмы надо бы поддерживать добавляя(и убирая) новые блоки на SOC, а не новые инструкции. Но это из области тех самых благих намерений...:(
                                                                                                                                          +1
                                                                                                                                          Да, это был бы хороший вариант. Для пользователя это бы выглядело, например, как область памяти, замапленную ему — и надо записать данные, команду и прочитать результат.
                                                                                                                                          Проблема с этим подходом, что он не интегрируется никак в OoO конвейер, не позволяет процессору выбрать, какое АЛУ будет исполнять, и так далее. Поэтому и работать с ним надо более крупными блоками. Например, SHA1 — лучше всего сказать ему «читай с этого адреса», а он дальше будет исполнять. Это уже криптопроцессор :) В чём-то вроде раутера, нацеленного на поддержку 100500 IPSec-соединений, такое точно будет — но в систему общего пользования ставить достаточно неудобно. Уже имеем аналогичный гимор с GPU: пока настроишь, пока данные в него вольёшь…
                                                                                                                                            0
                                                                                                                                            Да и еще один конкретный минус такого подхода — далеко не все кастомеры согласны использовать такого рода акселераторы (по разного рода причинам). Долго убеждал людей из одной ну очень большой конторы что видео надо транскодировать на акселераторе. Но так и не убедил.
                                                                                                                                          +3

                                                                                                                                          AES делают потому, что он плохо ложится на обычные команды процессора (приходится или табличками, что чревато атаками через кеш, или же долгими и нудными расчётами мультипликативной обратной величины). А чача хорошо ложится на SIMD, как и SHA-3 в общем-то.

                                                                                                                                            0
                                                                                                                                            Где-то такого комментария я и ожидал :) Спасибо за подтверждение, что данные команды не относятся к «универсальному набору» и предназначены для оптимизации одного конкретного частного применения.
                                                                                                                                        +1
                                                                                                                                        AVX512 кажется мне одной из самых дорогих ошибок Интела (эта тема наверно заслуживает отдельного поста). Три основные вещи — очередной префикс в Instruction set (ну это не самое страшное). Серьезный рост ядра по площали. Энергопторебление(!!!). С последней проблемой вообще справиться до конца не удалось. С задействованием AVX512 операций частота может просесть на 2-3 бина. И мы вместо прироста производительности получим убыль. Более того, частота выполнения становится непредскауземой и начинает зависеть от условия изготовлений кристалла.
                                                                                                                                        Я не верю, что это проблема интеловской имплементации. Над этим очень умные люди работают и это уже не первое поколение.
                                                                                                                                        А что в итоге? Ну ладно на линпаке (и части BLAS) получается почти двойка… Но на реальных бенчах куда меньше. На большом набор HPC прилаг я видел 8-11%
                                                                                                                                        Посмотрим что у Арма получится с SVE. Но у меня есть твердое убеждение что 256 бит -sweet spot. Нет в природе (существуюзщей базе софта) более длинных векторов.

                                                                                                                                    0
                                                                                                                                    Зависит от instruction throughput, а у некоторых он 1/4 такта (MOV, SUB, ADD, INC, CMP, NEG, NOT etc). Можно получить 4 инструкции за 1 такт.
                                                                                                                                      +1
                                                                                                                                      Разумеется, отдельные инструкции выполняются различное время, но на одних «быстрых» инструкциях программу создать затруднительно. Обычно для сравнения имеет смысл использовать статистические показатели, такие как средняя продолжительность исполнения инструкции при некой «средней» или «типичной» нагрузке
                                                                                                                                      +1
                                                                                                                                      На всех подобных архитектурах инструкции выполняются за много тактов. Можно сделать за один (особенно легко если разделить память инструкций и данных, у Harris+Harris пример, как это делается), но тогда такт будет длиной в самую медленную команду, а это никому не нужно — с DRAM это означает потерю скорости раз в 300.

                                                                                                                                      Реально же одна инструкция даже в идеале выполняется минимум за 2 такта (в первом выбрали из памяти, во втором декодировали и исполнили), полезная же — за минимум 4 (ещё выбрали данные, послали в АЛУ и, если повезёт, на этом же такте записали в выходной регистр). Где вы видите меньше — там качество конвейера, out-of-band блока и прочих, где пока первая команда пишет результат в память, вторая выполняется в АЛУ, третья собирает данные из регистров, четвёртая декодирована и ждёт старта, пятая как раз читается из памяти (пусть другой канал, чем первая пишет результат...)
                                                                                                                                      Показатель IPC (инструкций на такт) у x86 был <=1 только во времена приблизительно до Nehalem (2008). С наступлением Nehalem, Sandy Bridge и последующих, как окончательно закрылись возможности гонки по частоте — Intel и AMD начали оптимизировать именно параллельность в одном ядре, и теперь IPC=5 (то есть, в обратных цифрах, 0.2 такта на команду) не редкость. ARM'у не хватает инженеров, но уже пару лет как IPC=2 реальный тиражируемый результат.
                                                                                                                                        0
                                                                                                                                        > out-of-band блока
                                                                                                                                        Что-то меня со сна заглючило — везде следует читать out-of-order.
                                                                                                                                    0
                                                                                                                                    Интересно — а есть возможность писать ПО во внутреннем микрокоде ЦПУ, и если да то в таком случае было бы крайне сравнить эффективность. Сколько вся эта легаси обвязка «жрет» и энергии и «времени» ЦПУ.
                                                                                                                                      +1
                                                                                                                                      Да так оно примерно и происходит. Вот статья, откуда я позаимствовал графики. blog.acolyer.org/2017/06/19/hardware-is-the-new-software
                                                                                                                                      Если бы не этот ROM front end x86 давно превысил бы все разумные пределы. Там же оседают другие элементы ISA -например счетчики. Только этот ROM тоже не маленький и не бесплатный. Но поскольку все это не от хорошей жизни никто никогда не расскажет во что он обходится…
                                                                                                                                        0
                                                                                                                                        Можете почитать про сравнение моделей S/360 и S/370 (внутри каждого из этих рядов). Младшие модели обычно были максимально на микрокомандном исполнении инструкций стандартного набора, а старшие — на аппаратном исполнении вплоть до out-of-order. Разница в производительности доходила раз до 1000.

                                                                                                                                        Для x86, в микрокоде очень мало что полезно писать именно отдельными командами. Туда выносятся инициализация/самопроверка, сложные многоступенчатые операции типа входа/выхода VM, анклавов и т.п., обработки денормализованных (где они ещё не исправлены по сравнению с допотопной реализацией 1970-х) или команды, которые нахрен никому не нужны, но надо поддерживать ради легаси (как RCL/RCR). Выносить туда декодинг — они себе не могут позволить: даже если удастся разогнать этот внутренний автомат до 20 ГГц, его не хватит, чтобы успевать разрабатывать столь путаный поток байтов.
                                                                                                                                          0
                                                                                                                                          команды, которые нахрен никому не нужны, но надо поддерживать ради легаси (как RCL/RCR)

                                                                                                                                          А если постоянно постепенно выносить устаревшее вне кристалла, чтобы освобождать место? В итоге работать будет медленно, но работать.

                                                                                                                                        +1
                                                                                                                                        интересно, что получится, если pdp11 воплотить в железе на сегодняшних технологиях?
                                                                                                                                          +4
                                                                                                                                          микроконтроллер :)
                                                                                                                                            +6
                                                                                                                                            msp430
                                                                                                                                              +3
                                                                                                                                              Ну вообще можно сказать так — откуда вообще взялся CISC (а pdp-11 это CISC)? А взялся он из-за того что раньше памяти было мало, скорость исполнения маленькая, программы были простенькие, компиляторы и оптимизаторы убогенькие и желательно было (и иногда и нужно) писать все на ассемблере. Поэтому тут для удобства программистов нужен CISC. А потом появились крутые компиляторы куча ресурсов и смысла писать на ассемблере больше не стало. Соответственно и набор инструкций железа уже не имел значения. Поэтому набор инструкций x86 может быть ужасным — никто его не видит. И поэтому реализовал что-то вроде pdp/vax-11 смысла не имеет — никто это не почувствует, только разработчики компилятора. А в разработке компилятора все равно какой набор инструкций — всегда можно что-то подшаманить эффективно исходник переложит на пару кривых инструкций.
                                                                                                                                                +1

                                                                                                                                                Согласен. Всегда говорил, что не надо программистам мозги ассемблером забивать. У них и так есть баги, дедлайны и начальство. :) И компилятора тоже не надо, самый лучший язык — Java :)

                                                                                                                                                  +1
                                                                                                                                                  откуда вообще взялся CISC

                                                                                                                                                  Эта классификация появилась намного позже самого создания «CISC» процессоров.

                                                                                                                                                  Поэтому тут для удобства программистов нужен CISC.

                                                                                                                                                  Ничем не обоснованное, ложное утверждение. Сколько лет вы программировали на асме?
                                                                                                                                                    0
                                                                                                                                                    > Ничем не обоснованное, ложное утверждение. Сколько лет вы программировали на асме?

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

                                                                                                                                                    > Эта классификация появилась намного позже самого создания «CISC» процессоров.

                                                                                                                                                    Это абсолютно неважно. Подходы не теряют смысл от того, что они никак не названы или названы иначе, чем будут когда-нибудь потом.
                                                                                                                                                    +2
                                                                                                                                                    Про вторую часть — не совсем так.
                                                                                                                                                    Когда компилятор генерирует, грубо говоря, 99999 из 100000 исполняющихся процессором команд — оптимизация под компилятор становится безусловно важнее умений программиста. Можно под ту несчастную одну стотысячную долю организовать хорошо обученных людей (а не больше половины, как было в 70-е).
                                                                                                                                                    Дальше вопрос не в ресурсах, а в качестве самих компиляторов. Хорошая теория типа SSA — это уже 80-е и 90-е, когда основы x86 были заложены; до этого компиляторы делали код заведомо хуже человека, но с этого момента человеку надо хорошо учиться конкретной архитектуре, чтобы обогнать компилятор. С тех пор новых разработок типа CISC не делается — потому что SSA в разы легче ложится на RISC, чем CISC (трёхадресная типовая команда, отсутствие чтения-записи памяти в одной команде (атомарные — явное и дорогое исключение) и т.п.)
                                                                                                                                                    Вторым тут работает жутко медленная память, иерархия кэшей и как следствие — неизбежность out-of-order для нормальной работы; межъядерная синхронизация… — даже LL/SC требуют спецкостылей, а если бы заметная часть команд была чем-то вроде PDP-11 «ADD R1,2(R2)» — то скорость падала бы на порядки. Отсюда разложение CISC внутри на RISC микрооперации.
                                                                                                                                                    А x86 оказался заложником своего легаси — 32-битная архитектура уже была вся заточена на CISC-подходы без кэшей, out-of-order и многоядерности. AMD могли бы это исправить, но не захотели (возможно, от бедности) — в результате 64-битная система команд ещё хуже 32-битной (кроме отдельных микроулучшений вроде адресации по RIP), а Intel унёсся в небеса, думая, что сейчас все проблемы решатся, память станет быстрой, OoO станет не нужен и т.п. (это про IA64).
                                                                                                                                                    Вот с этим легаси и живём.
                                                                                                                                                      0
                                                                                                                                                      AMD могли бы это исправить, но не захотели (возможно, от бедности) — в результате 64-битная система команд ещё хуже 32-битной

                                                                                                                                                      Вероятно, просто на чип не помещалась бы эффективная реализация одновременно двух слишком разных наборов команд.
                                                                                                                                                        0
                                                                                                                                                        Им и так пришлось её сделать отдельно: в 64-битке часть опкодов уже работает иначе даже без префикса (некоторые команды с константами), заметно изменён разбор дополнительных байт адресации (какие-то варианты убраны, добавлено RIP-based), на верхнем уровне добавлены REX, убрана часть старых кодов…

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

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

                                                                                                                                                        Таки больше похоже на то, что авторам было облом слишком радикально менять.
                                                                                                                                                        0
                                                                                                                                                        Все так. Что то мне не видится, что память в обозримом будущем станет сравнимой с CPU по быстродействию. К тому же вижу все больше ворклоадов(cloud) где ключевой затычкой становится ожидание данных по сетке. Необходимость в скрывании латентностей только возрастает.
                                                                                                                                                      0
                                                                                                                                                      • Digital signal processors (DSPs) generally execute small, highly optimized audio or video processing algorithms. They avoid caches because their behavior must be extremely reproducible. The difficulties of coping with multiple address spaces are of secondary concern to speed of execution. Consequently, some DSPs feature multiple data memories in distinct address spaces to facilitate SIMD and VLIW processing. Texas Instruments TMS320 C55x processors, for one example, feature multiple parallel data buses (two write, three read) and one instruction bus.
                                                                                                                                                      • Microcontrollers are characterized by having small amounts of program (flash memory) and data (SRAM) memory, and take advantage of the Harvard architecture to speed processing by concurrent instruction and data access. The separate storage means the program and data memories may feature different bit widths, for example using 16-bit-wide instructions and 8-bit-wide data. They also mean that instruction prefetch can be performed in parallel with other activities. Examples include the PIC by Microchip Technology, Inc. and the AVR by Atmel Corp (now part of Microchip Technology).

                                                                                                                                                      Еще был такой эпизод:


                                                                                                                                                      In November 2007, to celebrate the project completion and to mark the start of a fundraising initiative for The National Museum of Computing, a Cipher Challenge[84] pitted the rebuilt Colossus against radio amateurs worldwide in being first to receive and decode three messages enciphered using the Lorenz SZ42 and transmitted from radio station DL0HNF in the Heinz Nixdorf MuseumsForum computer museum. The challenge was easily won by radio amateur Joachim Schüth, who had carefully prepared[85] for the event and developed his own signal processing and code-breaking code using Ada.[86] The Colossus team were hampered by their wish to use World War II radio equipment,[87] delaying them by a day because of poor reception conditions. Nevertheless, the victor's 1.4 GHz laptop, running his own code, took less than a minute to find the settings for all 12 wheels. The German codebreaker said: "My laptop digested ciphertext at a speed of 1.2 million characters per second—240 times faster than Colossus. If you scale the CPU frequency by that factor, you get an equivalent clock of 5.8 MHz for Colossus. That is a remarkable speed for a computer built in 1944."
                                                                                                                                                      +1

                                                                                                                                                      Если x86 такой устаревший, почему он такой быстрый?

                                                                                                                                                        +4
                                                                                                                                                        А кто говорил, что он устаревший. Я только говорил, что груз legacy велик. А так он живее всех живых :)
                                                                                                                                                          +2
                                                                                                                                                          Мало того, что живее всех живых, так совсем недавно подавляющее большинство новых айфонов имели на борту x86 процессор :) Правда в связи с недавним проигрышем Intel Qualcomm'у этот исторический зигзаг остается в истории.

                                                                                                                                                          Если кто не верит, то: lcq2.github.io/x86_iphone

                                                                                                                                                          ;)