OSDev

Ну и какие инструкции со времён 8008 устарели, и только мешаются в наборе инструкций AMD64? Может MOV устарела, или ADD какая-нибудь?

А кто говорит об устарелости?

Чем же они вам не нравятся? Они все одно- и двухбайтные, там декодировать нечего вообще. Причём этот набор инструкций составляет основную часть рабочего кода, а новые инструкции имеют вспомогательную роль, либо время их выполнения и их сложность намного выше, чем кодировка.

Изучили б матчасть, прежде чем глупости говорить, что ли... Код операции -- это не код команды, ну а последний может иметь от 1 до 15 байт длины, причём определить эту самую длину, а значит, и адрес следующей команды, не так-то просто (в общем случае для этого нужно проанализировать четыре или даже больше первых байтов).

Кодировка была довольно простой у 8086, но сама система команд оказалась крайне неэффективной -- в первую (но не единственную) очередь из-за совершенной неуниверсальности и невзаимозаменяемости того, что Интел имела наглость именовать "регистрами общего назначения". В частности, для адресации операндов в памяти могли использоваться только четыре регистра из восьми -- BX, BP, SI и DI, причём, если была необходима сумма двух регистров, одним из этих двух обязательно должен быть BX либо BP, а другим -- SI или DI; кроме того, при использовании BP обращение идёт к сегменту стека, что нередко требуется перекрыть префиксом изменения сегмента. Мало всего этого, так ещё кодирование байта, управляющего адресацией (RegModR/M), является "неортогональным", что усложняет аппаратный декодер, заставляя вводить в него лишние цепи, для обработки "неправильных" комбинаций.

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

Таким же идиотским путём пошла и AMD, которая не разработала новую кодировку, а прилепила очередной префикс. В результате по-прежнему имеем "несимметричный" набор регистров: нельзя произвольным образом использовать все вроде бы возможные комбинации старых и новых регистров, а кодирование команды различается в зависимости от того, какие регистры применяются. Ко всем предыдущим сложностям декодирования добавились новые, связанные с этим префиксом, ну а программисту или компилятору прибавилось работы по оптимальному распределению регистров и увязке их использования с длиной команды.

Кроме того, никуда не делась специализация регистров. Строковые операции -- только *SI, *DI и *CX, причём со строго определёнными сегментами. Знаковые и беззнаковые операции умножения-деления сильно различаются по своим операндам (хотя, с точки зрения здравого смысла, они должны быть вообще полностью идентичными и отличаться только алгоритмом обработки знака). Команды условной пересылки, столь полезные в теории, на практике не очень далеки от бесполезных, поскольку имеют приёмником регистр, а не регистр/память. Ну и т.д. и т.п.

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

Но ты ведь понимаешь, что при нефиксированной длине кода операции, необходим анализ последовательности байт? И что ты предлагаешь - фиксированный размер _всех_ кодов?

С другой стороны, специализация регистров немножко упрощает внутреннюю логику процессора :-)

К примеру, у PDP-11 и IBM/360 полный код команды мог занимать 2, 4 или 6 байтов, однако его длина всегда могла быть установлена по первым двум байтам (у IBM/360 -- вообще по двум старшим битам первого байта). Это намного упрощает выборку и декодирование команды. То, что системы команд этих машин имеют намного меньше инструкций, чем IA-32, аргументом не является, поскольку тут важен сам принцип -- единообразное кодирование команд с возможностью максимально быстрого определения длины команды, чтобы упростить выборку и декодирование. DEC, например, не стала извращаться, пытаясь сохранить бинарную совместимость в 32-разрядной VAX-11 с 16-разрядной PDP-11; вместо этого она реализовала отдельную 32-разрядную систему команд с нормальным кодированием плюс отдельный режим, в котором выполняла программы от PDP-11 (нечто вроде V86 на IA-32). Кстати говоря, по эффективности на коде общего назначения её никто так и не превзошёл, ну а всякие там SIMD... в конце 1970-х технологии ещё не позволяли пихать их в каждый компутер, для этого были специализированные матричные сопроцессоры к мэйнфреймам либо ещё более специализированные супер-ЭВМ.

Ну а фиксированный размер всех команд сделала ARM, на чём конкретно обломилась. Да, писать, используя родные АРМовские инструкции, приятно: они "ортогональны", все регистры равны между собой (ну, кроме счётчика команд, который доступен как регистр R15, а также регистров адреса возврата и указателя стека -- хотя два последних могут свободно использоваться как обычные РОНы, если по прямому назначению они не требуются), для каждой группы команд операнды используются одинаковым образом и имеют идентичные виды адресации независимо от конкретной команды... Однако каждая команда имеет размер 4 байта (концепция RISC требует равной длины под предлогом повышения скорости выборки команд), из-за чего память улетает впустую с дикой скоростью, а заодно и процессор тормозится (в микроконтроллерах программа обычно хранится в медленной флэш-памяти, а кэш жрёт много энергии и дорого стоит; когда RISC только выдумывали, никакой флэш-памяти не существовало, а разрыв в производительности процессора и пропускной способностью памяти был куда меньше, чем сейчас). Кинувшись исправлять ситуацию, ARM разродилась системой команд Thumb, наступив на те же грабли, но с противоположной стороны: каждая команда здесь имеет длину строго 2 байта (как же, это же RISC!), из-за чего им пришлось сильно ограничить функционал и сделать систему команд "неортогональной". Наконец, несколько лет назад до них дошло-таки, что для достижения высокой эффективности надо забить большой и толстый на принципы построения RISC-процессоров -- и появилась Thumb-2 с переменной длиной команды (2 или 4 байта). Но из-за сохранения совместимости по кодированию с обычной Тумбой само кодирование получилось уродским, хоть и не до такой степени, как в IA-32. Вот мне теперь интересно, как они 64-разрядный процессор лепить будут: озаботятся бинарной совместимостью или всё ж по-человечески сделают?..



Ни в коей мере. Скорей, наоборот, усложняет, поскольку при универсальных регистрах всё остальное тоже получается единообразным и универсальным, а при специализированных приходится либо лепить кучу специализированных же схем, что дополнительно раздувает аппаратуру (например, дополнительные инкременторы-декременторы для *SI и *DI и декрементор для *CX для обслуживания строковых операций, а заодно и дополнительные схемы управления), либо... опять-таки выполнять всё на общих универсальных блоках обработки (как это и имеет место на практике: нафига делать лишние блоки, которые будут почти всегда простаивать, если эти операции можно сделать на общем АЛУ?). Ну а декодирование команд по-любому серьёзно усложняется.

Проблема в том, что требуется инкремент-декремент трёх регистров одновременно, а АЛУ одно.
Ну а в целом согласен, что кодировку можно оптимизировать. Думаю, что когда ARM начнёт наступать на пятки Intel'у, то всё-таки выйдет новый i64 твоей мечты.

Нету такой проблемы, на самом-то деле, поскольку при выполнении строковых операций основное время занимает выборка данных из памяти и запись их в память, а АЛУ при этом занимается ровным счётом ничем. В самых первых процессорах (8086) совмещения операций не было, они там выполнялись строго последовательно, однако уже вскоре (пожалуй, уже в 80286, если говорить об интеловских процессорах) операции стали выполняться одновременно: пока производится чтение очередной порции из памяти, увеличивается или уменьшается *SI, при записи корректируется *DI, в какой-то из моментов и *CX обновляется... В современных же процессорах АЛУ имеется несколько штук (правда, не совсем симметричных: их лепят, исходя из частоты появления тех или иных команд и особенностей их спаривания; однако такие простые операции, как сложение, вычитание и логические, всегда реализованы в нескольких АЛУ, поскольку используются постоянно и практически всеми командами), поэтому все три инкремента-декремента могут выполняться в буквальном смысле одновременно. Конечно, такая схема намного сложней, но тут сложность объясняется стремлением повысить производительность, а не дефективностью системы команд: по большому счёту, в суперскалярных процессорах собственно система команд оказывает влияние лишь на блок выборки и декодирования команд, а всё остальное устроено более-менее одинаково.

Ну а новый i64 (правда, не "моей мечты") -- это Itanium, он же IA-64. Однако, как мы знаем, с рыночной точки зрения он провалился. Думаю, против него сыграли сразу несколько факторов: 1) низкая востребованность в 64-разрядных процессорах вообще (для суперзадач супермашины уже были, ну а конкурировать с "обычными" 32-разрядными серверами весьма сложно); 2) очень высокая сложность создания сколько-нибудь приличных компиляторов под эту архитектуру (с явным параллелизмом выполнения операций); 3) нехватка прикладного ПО (всё, что было, имелось и на других архитектурах, а вот много чего не было в принципе); 4) плохая эмуляция IA-32, не оправдавшая ожиданий потенциальных потребителей, да и самой Интел (вероятно, в значительной степени из-за п. 2 вкупе с крайне малым количеством специалистов, которые смогли бы создать эффективный эмулятор вручную, на ассемблере).

4) Именно, что ЭМУЛЯЦИЯ. Была бы предусмотрена аппаратная совместимость, процессор, может быть и пошёл бы.
Хотя...
...на бумаге и на синтетических тестах архитектуры EPIC и VLIW действительно бьют рекорды, но для них существенно возрастает сложность написания эффективных компиляторов, а на большинстве "невычислительных" задач эти архитектуры не демонстрируют ничего выдающегося (а то и проигрывают) при значительной "прожорливости" к памяти.
ARM получил весьма широкое распространение по той причине, что его аппаратная реализация весьма проста. Как следствие – малая площадь на кристалле и малое энергопотребление. У ARM наилучшее соотношение производительность/энергопотребление. Поэтому ему и прощают прожорливость к памяти и некоторую кривизну системы команд. Но у меня есть стопроцентная убеждённость, что можно сделать такую систему команд с переменной длиной опкода, которая позволила бы сделать как очень простой кристалл за счёт регулярности архитектуры и продуманной структуры команды, так и очень сложный (производительный) кристалл за счёт ёмкости системы команд и встроенных средств "на будущее".
С IBM/360 не работал, а по VAX-11 даже мучает ностальгия. Но надо сказать, эта архитектура живёт до сих пор, как великий Ленин! :)
http://ru.wikipedia.org/wiki/%D0%9B1839%D0%92%D0%9C1
http://www.angstrem.ru/products/micro/VAX-11-750/
Кстати, чтобы в тему. Почему бы ЭТО не использовать в системе ЖРВ, как поступает наша космонавтика?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Не первый раз вижу такую профонацию ARM. Но всё же, каким образом вы оценили отношение производительность/энергопотребление для x86, ARM, MIPS и др да ещё и второй вопрос тоже самое, но без использования синтетических тестов?