Comments 19
VLIW плачет в сторонке, про него забыли.
Попал в неудачную нишу. Для задач управления или вычислений где много-много неожиданных переходов - VLIW плох. Для линейных, хорошо распаралеливаемых вычислительных задач - выиграл подход gpu. Один набор команд и много-много ядер параллельно их исполняющих. VLIW оказался "между стульями".
На самом деле у VLIW есть своя ниша, это разные DSP, но о них мало кто знает. Даже о самом известном Hexagon от Qualcomm, также есть у Tensilica (ныне Cadence), было у CEVA (ныне тоже приобретена Cadence), есть у Интела в мобильных процессорах в IPU (Image Processing Unit) для обработки изображений с камеры.
Как видно, RISC доказал разработанную теории на практике — оказалось, что высокая плотность инструкций (характерная для CISC) мало влияет на общую производительность компьютера. Состав инструкций намного важнее.
Не соглашусь, для некоторых RISC это так, но для ARM нет, чтобы 32-бит не пропадали даром, в них запихнули несколько действий, которые можно сделать за одну команду (например, в дополнение к основному действию: сдвиг одного из операндов, условное выполнение по флагам, автоинкремент указателя). Поэтому плотность тоже высокая, всё зависит от реализации RISC архитектуры.
Тем не менее амбициозные планы привели MIPS Computer Systems к финансовым проблемам и поглощению.
А подробнее, в чём амбициозность и как это привело к провалу? По моему мнению, MIPS просто проиграли конкурентам по производительности, так что их чипы стали больше использоваться в качестве микроконтроллеров, чем для процессоров. Что характерно, MIPS имел ту самую низкую плотность инструкций.
Вывод статьи ни о чём. RISC может иметь сложное устройство и сложные инструкции, и высокую плотность, это давно уже не про Reduced, только провалившийся MIPS этому соответствовал. Само отношение архитектуры к RISC мало что говорит, успех зависит от конкретной реализации. ARМ пакует несколько действий в одну 32-бит команду, у китайского Loongarch64 пара тысяч векторных инструкций.
По моему мнению, MIPS просто проиграли конкурентам по производительности, так что их чипы стали больше использоваться в качестве микроконтроллеров, чем для процессоров.
деловая сторона (если правильно помню) выглядела примерно так, SGI купила MIPS в 1992 за примерно $300М, и продала в 2000 за примерно $1В, в общем резко изменив политику от противостояния Intel на сближение, отменив собственный проект H2, в который вложила достаточно средств, т.е. произошло примерно как с DEC alpha, и это был типа конец RISC для desktop, что для технологии было не очень (снова imho), а для Intel и MS вполне неплохо, про производительность вопрос непростой, но думаю что при прочих равных alpha была бы впереди, только делать ее некому было после того как Intel соответствующее отделение DEC купил, alpha конечно 64-bit RISC, архитектура была создана именно для scaling на много ядер, типа для рабочих станций, серверов и пр.
RISC-V только в чистой базе минималистичен, но в таком виде он даже в микроконтроллеры не ставится. Фишка RISC-V в модульности и настраиваемости, базовая ISA может имет огромное количество расширений на все случаи жизни и в сумме иметь больше поддерживаемых команд, чем какой нибудь CISC. Имея общую базу, стандарты и экосистему можно работать с risc-V от baterry-less микроконтроллеров для IoT до больших мощных универсальных молотилок (хотя пока они в основном в процессе разработки, до кремния еще не дорасли).
статья хорошего уровня, вероятно можно было бы чуть больше про ранние работы по системе команд CDC и Cray, упомянутый в статье IBM 7030 Stretch задуманный как супер компьютер не пошел в большой степени из-за своей сложности (особенно системы прерываний), это было учтено в разработках Seymour Cray, собственно его машины с простым набором команд показали на что способна подобная архитектура, конечно оказали влияние на RISC
По CISC:
число регистров ограничено, при этом каждый выполняет специализированную функцию.
"каждый" - это точно не про РОН в PDP-11. В указанной по ссылке статье о CiSC я тоже похожих утверждений о специализированности регистров вроде не заметил
Этот признак CISC из статьи, что вы выделили - мне тоже не понравился. Он уже неверен для современных x86. Сейчас команды использующие строго определённые регистры редко используются, а для большинства команд регистры универсальны. В x86_64 часть таких команд вообще удалили.
Из тех что используются на x86 - чаще всего это инструкция умножения с расширенным результатом, но в расширении BMI2 появилась инструкция mulx, где можно использовать любые регистры. Меж тем, у простых RISC команда умножения часто складывает результат в специальных регистрах (которые не являются общими регистрами).
Поэтому этот признак CISC из статьи некорректен, зависит от реализации.
Он никогда корректен не был. Скажем, Система 360 была анонсирована в 1964-м, первые модели поступили в продажу в 1965-м -- и её 16 регистров общего назначения были таки "общего назначения". Правда, в трёх экзотических командах использовался один жёстко определённый регистр (в Системе 370 число таких команд возросло до шести), но подавляющее большинство команд, в том числе все "нормальные", используют регистры на равноправной основе. Про PDP-11 выше тоже сказали; правда, указатель стека и счётчик команд относятся и адресуются как регистры общего назначения, хотя таковыми, по сути, не являются -- но то же самое относится и к ARM, например.
В общем, сей "признак" характерен либо для 8-разрядных микропроцессоров, либо для исключительно уродской системы команд 16-разрядного 8086/8088, но не для других современных последнему 16-разрядных микропроцессоров, например, Zilog Z8000.
Целый ряд неточностей, да и выводы сомнительны. Пройдусь по некоторым вещам.
Для начала -- о терминологии CISC и RISC -- это не архитектуры, это, если угодно, способы организации архитектур, но не сами архитектуры. И IA-32 (x86), и System/360, и PDP-11, и VAX-11 -- это всё CISCи, но совершенно разные, т.е. разные архитектуры. То же самое касается и RISCов.
Придерусь и к ISA, т.е. к instruction set architecture. Это -- не очень удачное определение, так как затрагивает только одну сторону вопроса, ведь архитектура -- это не только набор команд. Архитектура определяет и ряд других вещей, например, способы обработки прерываний. Можно, скажем, взять систему команд от VAX-11, но прицепить к ней обработку прерываний от M-профиля архитектуры ARM -- и что тогда получится? Это ведь будет уже и не VAX, и не ARM.
Насчёт конвейеризации. CISC, в общем и целом, на конвейер ложится ничуть не хуже RISCа. В частности, среди первых моделей Системы 360 старшая была уже конвейерной; из первых четырёх ЕС ЭВМ, которые архитектурно тоже были Системой 360, старшая -- ЕС-1050 -- была конвейерной, ну и т.д. Более того, в 1960-х появились и первые суперскалярные процессоры, и даже процессоры с внеочередным (out-of-order) выполнением команд. Просто тогда это был удел буквально нескольких машин во всём мире, а сейчас такое чуть ли не в каждом утюге встречается -- но это является следствием развития микроэлектроники.
Далее, начсёт частоты использования команд и их влияния на производительность. Да, простые команды используются намного чаще, и это было неправильно воспринято некоторыми как возможность "безнаказанно" избавиться от сложных команд. Результатом стал, в частности, MIPS. На сравнительно небольшом промежутке времени -- в 1980-90-х -- это, действительно, позволило добиться превосходства в производительности над вычислительными системами аналогичных массо-габаритных характеристик и себестоимости, но причина крылась в другом: тогдашние технологии уже позволяли впихнуть простой процессор в одну микросхему, но не позволяли сделать этого для сложного процессора (или позволяли, но только с чисто микропрограммным управлением, без конвейера или с очень простым конвейером). Соответственно, MIPS, будучи выполнен в виде одной микросхемы, мог работать на высокой тактовой частоте и при этом реализовывать конвейерное выполнение команд, а какой-нибудь 80386 -- не мог. Вот топовый мэйнфрейм рвал по производительности и 80386, и MIPS, как тузик грелку -- только его не поставить было не только на стол, но даже и в небольшую комнату.
Но так было до тех пор, пока не появилась возможность впихнуть сложный процессор с конвейером и всем прочим на один кристалл. И постепенно CISCи, в общем и целом (а не на специализированных задачах -- это важно!), снова вырвались вперёд. Причина кроется, в частности, в низкой плотности кода, характерной для RISCов: тактовые частоты процессоров росли куда быстрее, чем пропускная способность и особенно латентность памяти. Конечно, наличие кэшей снижало остроту проблемы, но ведь и CISCи умеют пользоваться кэшами, при этом, из-за более высокой плотности кода, им нужен куда меньший кэш команд.
Более того, наличие команд для реализации достаточно сложных алгоритмов, скажем, вычисления хэшей и прочего шифрования, поднимает производительность на этих задачах иногда в десятки раз. Причина здесь не только в исключении лишних выборок и декодирования простых команд (выбрана и декодирована одна сложная команда -- и процессор побежал её выполнять), но и в том, что процессор, выполняя такую команду, точно знает, какие доступы к памяти данных ему потребуются, в каком порядке они будут идти и т.п. -- а значит, может максимально оптимизировать обращения к данным, чего в обычной программе добиться невозможно -- а это критично для высокой производительности из-за уже упомянутой пропускной способности и латентности памяти. (Кстати, для программной оптимизации современные процессоры содержат команды-подсказки, дающие процессору возможность заблаговременно подгрузить данные, которые потребуются в будущем -- но это лишь суррогат).
По этим причинам в современных RISCах от изначальной идеологии RISC мало что осталось. Скажем, современные ARMы сохранили лишь невозможность прямой обработки данных в памяти -- их требуется загружать для этого в регистры. Однако у них переменная длина кода команды, переменное время выполнения команды, а сам полный набор команд насчитывает не одну сотню (для сравнения: у Системы 360 полный набор включал всего лишь 143 команды). В общем, в нынешнем ARMе наличествуют почти все черты типичного CISCа. Конечно, кодирование команд в ARM многократно проще, чем в IA-32 (x86), но последняя -- пример того, какой не должна быть система команд, а особенно -- её кодирование; она отвратительна со всех точек зрения. А вот команды Системы 360 или, скажем, PDP-11 декодировать ничуть не сложней, чем команды ARM, -- хотя они являются самыми что ни на есть настоящими CISCами.
Ну и насчёт сложности процессоров. Процессор какой-нибудь ЕС-1020 или System/360 model 30 ощутимо проще, чем даже жутко примитивное ядро Cortex-M3 M-профиля архитектуры ARM, не говоря уже о всяких там Core i-100500. Основную сложность создаёт не система команд как таковая и даже не конвейер, а реализация суперскалярного и особенно внеочередного выполнения команд. Дурное кодирование команд в IA-32 резко усложняет задачу их декодирования (попробуй, хотя бы, определи длину команды!), но после декодирования, по большому счёту, особых сложностей с выполнением команд нет. Ну и ничто не мешает реализовывать простые команды чисто аппаратным управлением, а сложные -- аппаратно-микропрограммным: какое-нибудь микропрограммное шифрование будет выполняться всяко быстрее, чем тот же самый алгоритм, реализованный чисто программными средствами, а дополнительных аппаратных затрат требует мизер.
небольшое дополнение - пользу конвейеризации начали понимать очень рано, задолго до System/360, типа Zuze Z3 патент 1949 года "Execution pipeline with overlap of instructions", Turing ACE (1946), Amdahl WISC (1950), IBM Stretch, CDC 6600, в зависимости от возможностей hw и sw, т.е. всегда компромисс удачный как CDC 6600/7600, или неудачный как IBM Stretch, действительно прямого отношения к RISC не имеет
Безусловно. Ни первой конвейерной, ни первой суперскалярной S/360 не была; вот внеочередное выполнение команд, кажется, впервые реализовали таки на одной из моделей этого семейства в самом конце 1960-х. Но, возможно, IBM стала первой, кто все эти вещи стал внедрять в относительно массовых вычислительных системах, а не в единичных исследовательских проектах или супер-ЭВМ.
обычно считается CDC 6600 (1964), если правильно помню в IBM 360/91 (1967) это реализовано для floating point, заметим CDC 6600 было установлено около сотни, а 360/91 порядка 15, из них 4 внутри самой IBM + две 360/95, но хотели сделать еще для IBM Stretch 7030 (1957-61), но там сложная система прерываний была которая сильно тормозила + другие трудности, только упростив удалось сделать более-менее удачную 360/91, тогда как CDC 6600 это чистый дизайн вообще (почти) без прерываний i/o, Seymour Cray конечно учитывал опыт 7030
ps - выше про внеочередное выполнение команд
Внутри V1 было всего 27 000 транзисторов. Например, в Intel 80286 их было 134 000. При этом ARM работал в 10 раз быстрее 80286. Энергопотребление V1 не превышало 1 Вт.
А что за чудестный процессор и в 10 раз быстрее а 86/64 кругом а не он(на дэсктоп/сервер)? как же так?
ЗЫ. Поправлюсь. Я просто когда вижу что по бэнчам в что-то А быстрее чего-то Б, то первый возникающий вопрос: а что именно стравнивали и как? Потому, что можно же стравнить разные вещи разными бенчмарками. Или 10 - это общая производительность (повседневная), ну тогда мой вопрос про почему мы все еще на х64 валиден)
Там дальше еще смешнее:
Недостатки тоже были:
Не было встроенной кэш‑памяти.
Не было схем умножения и деления.
Не было модуля с плавающей (float) запятой, отчего операции с нецелыми числами выполнялись медленно.
Чип работал на скромной частоте 6 МГц. В те годы 32-битный процессор Motorola 68 020 имел 17 МГц. Однако мощность у них была одинаковая.
Был в 10 раз быстрее, но не было схем умножения и деления. Круто.
Ретроспективный взгляд на развитие микропроцессоров CISC, RISC, MIPS, ARM