Как языки повлияли на дизайн процессора? [закрыто]

Нам часто говорят, что аппаратному обеспечению не важно, на каком языке написана программа, поскольку оно видит только скомпилированный двоичный код, однако это не вся правда. Например, рассмотрим скромный Z80; его расширения к набору команд 8080 включают в себя такие инструкции, как CPIR, которые полезны для сканирования строк в стиле C (с нулевым символом в конце), например, для выполнения strlen(). Разработчики, должно быть, определили, что запуск программ на C (в отличие от Pascal, где длина строки находится в заголовке) - это то, для чего их дизайн, вероятно, будет использоваться. Другой классический пример - машина Лиспа .

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

Существующие ответы сосредоточены на изменениях ISA . Есть и другие аппаратные изменения. Например, C ++ обычно использует виртуальные таблицы для виртуальных вызовов. Начиная с Pentium M , в Intel появился компонент «косвенный предсказатель ветвления», который ускоряет вызовы виртуальных функций.

Набор команд Intel 8086 включает в себя вариант «ret», который добавляет значение к указателю стека после получения адреса возврата. Это полезно для многих реализаций Pascal, когда вызывающая функция помещает аргументы в стек перед выполнением вызова функции и выводит их позже. Если подпрограмма будет принимать, например, четыре байта параметров, она может закончиться «RET 0004» для очистки стека. В отсутствие такой инструкции такое соглашение о вызовах, вероятно, потребовало бы, чтобы код вставлял адрес возврата в регистр, обновлял указатель стека и затем переходил в этот регистр.

Интересно, что большинство кода (включая подпрограммы ОС) на исходном Macintosh использовали соглашение о вызовах Pascal, несмотря на отсутствие упрощающей инструкции в 68000. Использование этого соглашения о вызовах позволило сэкономить 2-4 байта кода на типичном сайте вызовов, но потребовало дополнительного 4-6 байт кода на сайте возврата каждой функции, которая принимала параметры.

Одним из примеров является MIPS, который имеет как addи adduдля перехвата и игнорирования переполнения соответственно. (Также subи subu.) Требовался первый тип инструкций для языков, таких как Ada (я думаю, я никогда не использовал Ada), которые явно имеют дело с переполнениями, и второй тип для языков, подобных C, которые игнорируют переполнения.

Если я правильно помню, фактический процессор имеет некоторые дополнительные схемы в ALU для отслеживания переполнений. Если бы единственный язык, который заботился о людях, был C, это бы не нуждалось в этом.

Серия Burroughs 5000 была разработана для эффективной поддержки ALGOL, а Intel iAPX-432 была разработана для эффективной работы Ada. У Inmos Transputer был свой собственный язык, Оккам. Я думаю, что процессор Parallax "Propeller" был разработан для программирования с использованием своего собственного варианта BASIC.

Это не язык, но набор инструкций VAX-11 содержит одну инструкцию для загрузки контекста процесса, которая была разработана по запросу команды разработчиков VMS. Я не помню деталей, но ISTR потребовалось так много инструкций, чтобы реализовать серьезный верхний предел количества процессов, которые они могли запланировать.

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

Семейство Motorola 68000 представило несколько режимов автоинкремента, которые сделали копирование данных через процессор очень эффективным и компактным.

[Обновленный пример]

это был некоторый код C ++, который повлиял на ассемблер 68000

while(someCondition)
    destination[destinationOffset++] = source[sourceOffset++]

реализован в обычном ассемблере (псевдокод, я забыл 68000 команд ассемблера)

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1)
    move (adressRegister2), akku
    increment(adressRegister1, 1)
    increment(adressRegister2, 1)
}

с новым адресным режимом это стало чем-то похожим на

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1++)
    move (adressRegister2++), akku
}

только две инструкции в цикле вместо 4.

Мэйнфрейм IBM серии Z является потомком IBM 360 1960-х годов.

Там было несколько инструкций, специально предназначенных для ускорения программ на COBOL и Fortran. Классическим примером является BXLE«Ветвь по индексу с низким или равным», которая представляет собой большую часть forцикла Фортрана или COBOL, PERFORM VARYING x from 1 by 1 until x > nинкапсулированных в одну инструкцию.

Существует также целое семейство упакованных десятичных инструкций для поддержки десятичной арифметики с фиксированной запятой, распространенной в программах на языке COBOL.

Ранние процессоры Intel имели следующие функции, многие из которых теперь устарели в 64-битном режиме:

• Инструкции ENTER, LEAVE и RET nn [в ранних руководствах было подробно сказано, что они были введены для блочно-структурированных языков, например, Pascal, который поддерживает вложенные процедуры]
• инструкции по ускорению арифметики BCD (AAA, AAM и т. д.); также поддержка BCD в x87
• Инструкции JCXZ и LOOP для реализации подсчитанных циклов
• INTO, для генерации ловушки при арифметическом переполнении (например, в Ada)
• XLAT для поиска по столу
• BOUND для проверки границ массива

Флаг знака, найденный в регистре состояния многих процессоров, существует для простой выполнения арифметики со знаком и без знака.

Набор инструкций SSE 4.1 представляет инструкции для обработки строк, как с нулевым, так и с нулевым окончанием (PCMPESTR и т. Д.)

Кроме того, я мог бы представить, что ряд функций системного уровня был разработан для обеспечения безопасности скомпилированного кода (проверка предела сегмента, шлюзы вызовов с копированием параметров и т. Д.)

Некоторые процессоры ARM, в основном мобильные, включают в себя (d) расширение Jazelle, которое является аппаратным интерпретатором JVM; он интерпретирует байт-код Java напрямую. JVM, поддерживающая Jazelle, может использовать аппаратное обеспечение для ускорения выполнения и устранения большей части JIT, но резервирование виртуальной машины программного обеспечения все еще гарантируется, если байт-код не может быть интерпретирован на кристалле.

Процессоры с таким модулем включают в себя инструкцию BXJ, которая переводит процессор в специальный «режим Jazelle», или, если активация модуля не удалась, она просто интерпретируется как обычная команда перехода. Устройство повторно использует регистры ARM для хранения состояния JVM.

Преемником технологии Jazelle является ThumbEE

Насколько я знаю, это было более распространенным в прошлом.

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

Он упомянул, что есть преимущество в использовании универсального популярного чипа (такого как Intel), потому что у него есть крупная корпорация, которая тратит огромные суммы денег на продукт.

Видео стоит проверить. Он говорит об этом на 19 или 20 минуте.

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

Процессор Intel iAPX был специально разработан для ОО-языков. Не совсем получилось, хотя.

IAPX 432 ( Intel Advanced Processor архитектура ) был первый 32-разрядный микропроцессор Intel, дизайн, введенный в 1981 году в виде набора из трех интегральных схем. Он был задуман как основной проект Intel для 1980-х годов, в котором реализованы многие передовые функции многозадачности и управления памятью. Таким образом, дизайн был назван Micromainframe ...

IAPX 432 был «спроектирован так, чтобы полностью программироваться на языках высокого уровня» , причем Ada была основной и поддерживала объектно-ориентированное программирование и сборку мусора непосредственно в аппаратном обеспечении и микрокоде . Прямая поддержка различных структур данных была также предназначена для того, чтобы современные операционные системы для iAPX 432 могли быть реализованы с использованием гораздо меньшего количества программного кода, чем для обычных процессоров. Эти свойства и особенности привели к созданию аппаратного и микрокодов, который был намного сложнее, чем большинство процессоров той эпохи, особенно микропроцессоры.

Используя современную полупроводниковую технологию, инженеры Intel не смогли перевести проект в очень эффективную первую реализацию. Наряду с отсутствием оптимизации в преждевременном компиляторе Ada это способствовало довольно медленным, но дорогостоящим компьютерным системам, которые выполняли типичные тесты примерно на 1/4 скорости нового чипа 80286 на той же тактовой частоте (в начале 1982 года).

Этот первоначальный разрыв в производительности с довольно низкопрофильной и недорогой линией 8086, вероятно, был основной причиной, по которой план Intel заменить последний (позже известный как x86) на iAPX 432 провалился. Хотя инженеры нашли способы улучшить дизайн следующего поколения, архитектура iAPX 432 Capability теперь стала восприниматься скорее как накладные расходы на реализацию, а не как упрощенная поддержка, которой она должна была быть.

Проект iAPX 432 был коммерческим провалом для Intel ...

У 68000 был MOVEM, который больше всего подходил для помещения нескольких регистров в стек в одной инструкции, чего и ожидали многие языки.

Если вы видели MOVEM (MOVE Multiple), предшествующий JSR (Jump SubRoutine) по всему коду, то вы, как правило, знали, что имеете дело с C-совместимым кодом.

MOVEM допускает автоматическое увеличение регистра назначения, позволяя при каждом использовании продолжать наложение на место назначения или удаление из стека в случае автоматического уменьшения значения.

http://68k.hax.com/MOVEM

Архитектура Atmel AVR полностью разработана с нуля для того, чтобы она подходила для программирования на C. Например, эта заметка по применению уточняется далее.

IMO, это тесно связано с отличным ответом rockets4kids: ранние PIC16 разрабатывались для прямого программирования на ассемблере (всего 40 инструкций), а более поздние семейства нацелены на C.

Когда был разработан числовой сопроцессор 8087, для языков было довольно распространенным делом выполнять всю математику с плавающей запятой, используя тип с наивысшей точностью, и округлять результат только до более низкой точности при назначении его переменной с более низкой точностью. В исходном стандарте C, например, последовательность:

float a = 16777216, b = 0.125, c = -16777216;
float d = a+b+c;

будет способствовать aи bк double, добавить их, поощрять cк double, добавьте его, а затем сохранить результат округляется до float. Хотя во многих случаях компилятору было бы быстрее генерировать код, который выполнял бы операции непосредственно над типом float, было проще иметь набор подпрограмм с плавающей запятой, которые будут работать только над типом double, вместе с подпрограммами для преобразования в / от float, чем иметь отдельные наборы подпрограмм для обработки операций floatи double. 8087 был разработан вокруг этого подхода к арифметике, выполняя все арифметические операции с использованием 80-битного типа с плавающей запятой [80 битов, вероятно, было выбрано, потому что:

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

2. Очень трудно выполнять вычисления, которые являются точными с полной точностью используемых числовых типов; например, если кто-то пытается вычислить что-то вроде log10 (x), проще и быстрее вычислить результат с точностью до 100 муль для 80-битного типа, чем для вычисления результата с точностью до 1 муль от 64-битного тип и округление первого результата до 64-битной точности даст 64-битное значение, которое является более точным, чем второе.

К сожалению, будущие версии языка изменили семантику того, как должны работать типы с плавающей точкой; в то время как семантика 8087 была бы очень полезной, если бы языки поддерживали их последовательно, если бы функции f1 (), f2 () и т. д. возвращали тип float, многие авторы компилятора сами long doubleвзялись бы за создание псевдонима для 64-битного двойного типа а не 80-битный тип компилятора (и не предоставляют никаких других средств для создания 80-битных переменных), и произвольно оценивать что-то вроде:

double f = f1()*f2() - f3()*f4();

любым из следующих способов:

double f = (float)(f1()*f2()) - (extended_double)f3()*f4();
double f = (extended_double)f1()*f2() - (float)(f3()*f4());
double f = (float)(f1()*f2()) - (float)(f3()*f4());
double f = (extended_double)f1()*f2() - (extended_double)f3()*f4();

Обратите внимание, что если f3 и f4 возвращают те же значения, что и f1 и f2 соответственно, исходное выражение должно явно возвращать ноль, но многие из последних выражений могут и не быть. Это привело к тому, что люди осудили «дополнительную точность» 8087, хотя последняя формулировка обычно превосходила бы третью и - с кодом, соответствующим образом использующим расширенный тип double, - редко бы уступала.

За прошедшие годы Intel отреагировала на тенденцию языка (ИМХО) к тому, чтобы заставить промежуточные результаты округляться до точности операндов, проектируя свои более поздние процессоры, чтобы способствовать такому поведению, в ущерб коду, который выиграл бы от использования более высоких точность промежуточных расчетов.