Як мови вплинули на дизайн процесора? [зачинено]

Нам часто кажуть, що апаратне забезпечення не хвилює, на якій мові написана програма, оскільки вона бачить лише скомпільований двійковий код, однак це не вся правда. Наприклад, розгляньте скромну Z80; його розширення до набору інструкцій 8080 включають такі інструкції, як CPIR, які корисні для сканування рядків у стилі C (з NULL), наприклад для виконання strlen(). Дизайнери, мабуть, визначили, що запуск програм C (на відміну від Pascal, де довжина рядка знаходиться в заголовку) - це те, для чого, ймовірно, використовувався їх дизайн. Ще один класичний приклад - машина Lisp .

Які ще приклади є? Наприклад, інструкції, кількість та тип регістрів , режими адресації, завдяки яким певний процесор надає перевагу умовам певної мови? Мене особливо цікавлять ревізії тієї ж родини.

Існуючі відповіді фокусуються на змінах ISA . Є й інші апаратні зміни. Наприклад, C ++ зазвичай використовує Vtables для віртуальних дзвінків. Починаючи з 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 для відстеження переливів. Якби єдиною мовою, про яку люди піклувались, була С, це не потребувало б.

Серія Burroughs 5000 була розроблена для ефективної підтримки ALGOL, а iAPX-432 від Intel був розроблений для ефективного виконання Ada. У комп’ютера Inmos була своя мова, Occam. Я думаю, що процесор 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, для створення пастки на арифметичному переливі (наприклад, в Ада)
• XLAT для пошуку таблиць
• БУНД для перевірки меж масиву

Прапор знака, знайдений в реєстрі статусу багатьох процесорів, існує для того, щоб легко виконувати арифметичні підписані та неподписані.

Набір інструкцій SSE 4.1 вводить інструкції для оброблення рядків, як підраховані, так і з нульовим завершенням (PCMPESTR тощо)

Крім того, я міг уявити, що ряд функцій на рівні системи був розроблений для підтримки безпеки компільованого коду (перевірка обмеження сегмента, ворота викликів з копіюванням параметрів тощо)

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

Процесори з таким блоком включають інструкцію BXJ, яка переводить процесор у спеціальний режим "Jazelle", або якщо активація блоку не вдалася, вона просто інтерпретується як звичайна гілка інструкція. Пристрій повторно використовує регістри ARM для утримання стану JVM.

Наступником технології Jazelle є ThumbEE

Наскільки мені відомо, це було більш поширеним у минулому.

Є сесія запитань, в якій Джеймс Гослінг сказав, що люди намагаються зробити апаратне забезпечення, яке б краще справлялося з байт-кодом JVM, але тоді ці люди знайдуть спосіб зробити це із загальним "загальним" Intel x86 (можливо, компілюючи байт-код якось розумним чином).

Він зазначив, що в використанні загального популярного чіпа (наприклад, Intel) є перевага, оскільки велика корпорація кидає на продукт величезні суми грошей.

Відео варто переглянути. Про це він говорить у 19 чи 20 хвилини.

Я зробив швидкий пошук сторінки, і, здається, ніхто не згадав процесор, розроблений спеціально для виконання Forth . Мова програмування Forth заснована на стеках, компактна і використовується в системах управління.

Процесор Intel iAPX був спеціально розроблений для мов OO. Не дуже вийшло, хоча.

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

AVR-архітектура Atmel повністю розроблена з нуля, щоб вона була придатною для програмування в 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), то простіше і швидше обчислити результат, який точно в межах 100ulp 80-бітного типу, ніж обчислити результат, точний в межах 1ulp 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 року, хоча остання формулювання, як правило, перевершує третю і - з кодом, який використовує розширений подвійний тип, - рідко буде неповноцінним.

У наступні роки Intel відповіла на мовну (нещасну IMHO) тенденцію до примушення проміжних результатів до окружності до точності операндів, розробляючи їх більш пізні процесори, щоб сприяти такій поведінці, на шкоду коду, який би виграв від використання вищих точність на проміжних розрахунках.