Екзотична архітектура, про яку піклуються комітети зі стандартів

Я знаю, що стандарти C і C ++ залишають багато аспектів мовної реалізації лише тому, що якщо існує архітектура з іншими характеристиками, було б складно або неможливо написати стандартний відповідний компілятор для неї.

Я знаю, що 40 років тому будь-який комп'ютер мав свою унікальну специфікацію. Однак я не знаю жодної архітектури, яка використовується сьогодні, де:

• CHAR_BIT != 8
• signed не є доповненням двох (я чув, що у Java були проблеми з цим).
• Плаваюча точка не відповідає IEEE 754 (Редагувати: я мав на увазі "не в двійковому кодуванні IEEE 754").

Причина, про яку я питаю, полягає в тому, що я часто пояснюю людям, що добре, що C ++ не надає жодних інших аспектів низького рівня, таких як типи фіксованого розміру ^† . Це добре, тому що на відміну від "інших мов", він робить ваш код переносним при правильному використанні (Редагувати: тому, що він може бути перенесений до більшої кількості архітектур, не вимагаючи емуляції аспектів низького рівня машини, як, наприклад, арифметика двох доповнення на архітектурі знака + величини) . Але мені погано, що я сам не можу вказати на якусь конкретну архітектуру.

Тож питання: які архітектури виявляють вищевказані властивості?

† uint*_ts необов’язкові.

Погляньте на цей

Сервери Unisys ClearPath Dorado

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

Ключові моменти:

• 36-бітні слова
• CHAR_BIT == 9
• доповнення
• 72-бітна плаваюча точка не IEEE
• окремий адресний простір для коду та даних
• слово адресоване
• немає виділеного вказівника стека

Не знаю, чи пропонують вони компілятор C ++, але вони могли .

А тепер з'явилося посилання на останнє видання їх посібника С:

Посібник із програмування для компілятора Unisys C

У розділі 4.5 є таблиця типів даних з 9, 18, 36 та 72 бітами.

Жодне з ваших припущень не стосується мейнфреймів. Для початку я не знаю мейнфрейму, який використовує IEEE 754: IBM використовує плаваючу точку бази 16, а обидві основні рамки Unisys використовують базу 8. Машини Unisys дещо особливі у багатьох інших аспектах: Бо згадав 2200 архітектура, але MPS-архітектура навіть незнайома: 48 бітових тегів. (Чи є слово вказівником чи ні, залежить від біта у слові.) А числові подання побудовані так, щоб не було реального розмежування між плаваючою точкою та інтегральною арифметикою: плаваюча точка є базовою 8; вона не вимагає нормалізації, і на відміну від усіх інших плаваючої точки, яку я бачив, вона ставить десятковий правий від мантіси, а не лівий, і використовує підписану величину для експонента (крім мантіси). За результатами, що інтегральне значення з плаваючою комою має (або може мати) точно таке ж бітове подання, як ціле число підписаної величини. І немає арифметичних вказівок з плаваючою комою: якщо експоненти двох значень обидва 0, інструкція робить інтегральною арифметикою, інакше вона має арифметику з плаваючою комою. (Продовження філософії мітки в архітектурі.) Що означає, що покиint може займати 48 біт, з них 8 має бути 0, або значення не розглядатиметься як ціле число.

Повна відповідність IEEE 754 зустрічається рідко в реалізаціях з плаваючою комою. І ослаблення специфікації в цьому плані дозволяє безліч оптимізацій.

Наприклад, підтримка субнорми відрізняється між x87 та SSE.

Оптимізації, такі як злиття множення та додавання, які були окремими у вихідному коді, теж трохи змінюють результати, але приємна оптимізація для деяких архітектур.

Або в x86 суворому дотриманні IEEE може знадобитися встановлення певних прапорів або додаткових передач між регістрами плаваючої точки та звичайною пам'яттю, щоб змусити його використовувати вказаний тип плаваючої точки замість внутрішніх 80-бітних плавців.

А деякі платформи взагалі не мають апаратних плаваючих механізмів, і тому їх потрібно емулювати в програмному забезпеченні. І деякі вимоги IEEE 754 можуть бути дорогими для впровадження в програмному забезпеченні. Зокрема, можуть бути проблемою правила округлення.

Мій висновок полягає в тому, що вам не потрібні екзотичні архітектури, щоб потрапити в ситуації, якщо ви не завжди хочете гарантувати суворе дотримання IEEE. З цієї причини мало мов програмування гарантували чітке дотримання IEEE.

Я знайшов це посилання з переліком деяких систем, де CHAR_BIT != 8. Вони включають

деякі TI DSP є CHAR_BIT == 16

Чип BlueCore-5 (чіп Bluetooth від Cambridge Silicon Radio), який має CHAR_BIT == 16.

І, звичайно, є питання щодо Stack Overflow: Які платформи мають щось інше, ніж 8-бітовий char

Щодо систем, що не доповнюють двох, є цікаве прочитання на модерації comp.lang.c ++ . Узагальнено: є платформи, що мають доповнення або знак та величину.

Я досить впевнений, що системи VAX досі використовуються. Вони не підтримують IEEE з плаваючою точкою; вони використовують власні формати. Альфа підтримує формати з плаваючою точкою VAX та IEEE.

Cray векторні машини, як і T90, також мають власний формат з плаваючою комою, хоча новіші системи Cray використовують IEEE. (Використовуваний T90 був виведений з експлуатації кілька років тому; я не знаю, чи все ще активне використання.)

T90 також мав / має цікаві подання для покажчиків та цілих чисел. Народна адреса може вказувати лише на 64-бітове слово. Компілятори C і C ++ мали CHAR_BIT == 8 (необхідна тому, що вона використовувала Unicos, аромат Unix і повинен був взаємодіяти з іншими системами), але рідна адреса могла вказувати лише на 64-бітове слово. Усі операції на рівні байтів були синтезовані компілятором, і void*абоchar* зберігають зміщення байтів у 3-бітових словах високого порядку. І я думаю, що деякі цілі типи мали біти підкладки.

Мейнфрейми IBM - ще один приклад.

З іншого боку, саме ці системи повинні не обов'язково виключає зміни в стандарт мови. Cray не виявив особливого інтересу до оновлення свого компілятора C до C99; мабуть те саме, що застосовується до компілятора C ++. Це може бути доцільним посилити вимоги до реалізації розміщених, наприклад, вимагають CHAR_BIT == 8, формат IEEE з плаваючою точкою , якщо не в повній семантиці, і 2's-комплемент без заповнення біт для цілих чисел. Старі системи могли продовжувати підтримувати більш ранні мовні стандарти (C90 не загинув, коли з'явився C99), і вимоги можуть бути слабкішими для самостійно реалізованих реалізацій (вбудованих систем), таких як DSP.

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

CHAR_BITS

Відповідно до вихідного коду gcc :

CHAR_BITє 16бітами для архітектури 1750a , dsp16xx .
CHAR_BITє 24бітами для архітектури dsp56k .
CHAR_BITє 32бітами для архітектури c4x .

Ви можете легко знайти більше, зробивши:

find $GCC_SOURCE_TREE -type f | xargs grep "#define CHAR_TYPE_SIZE"

або

find $GCC_SOURCE_TREE -type f | xargs grep "#define BITS_PER_UNIT"

якщо CHAR_TYPE_SIZEце належним чином визначено.

Відповідність IEEE 754

Якщо архітектура цілі не підтримує інструкції з плаваючою комою, gcc може генерувати програмне забезпечення відьом, яке не є стандартним стандартом. Більше того, можна використовувати спеціальні параметри (наприклад, -funsafe-math-optimizationsвідьма також вимикає збереження знаків для нулів).

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

EDIT: у коментарях було поставлено питання, чи плаваюча точка GPU має відношення до звичайного комп'ютерного програмування, не пов'язаного з графікою. Так, чорт візьми! Найбільш високопродуктивна річ, що обчислюється сьогодні, робиться на графічних процесорах; до списку входять AI, обмін даними, нейронні мережі, фізичні симуляції, прогноз погоди та багато іншого. Одне з посилань у коментарях показує, чому: порядок переваги GPU.

Ще одне, що я хотів би додати, що більше стосується питання про ОП: що люди робили 10-15 років тому, коли плаваючою точкою GPU не був IEEE і коли для програмування графічних процесорів не було API, таких як сьогодні OpenCL або CUDA? Вірите чи ні, першим піонерам обчислювальних процесорів GPU вдалося запрограмувати GPU без API, щоб це зробити ! Я зустрів одного з них у своїй компанії. Ось що він зробив: він закодував дані, необхідні для обчислення у вигляді зображення з пікселями, що представляють значення, над якими він працював, а потім використовував OpenGL для виконання потрібних йому операцій (наприклад, "гауссова розмиття" для подання згортки з нормальним розподілом тощо) і декодував отримане зображення назад у масив результатів. І це все-таки було швидше, ніж використання процесора!

Такі речі спонукали NVidia нарешті зробити свої внутрішні бінарні дані сумісними з IEEE та запровадити API, орієнтований на обчислення, а не маніпулювання зображеннями.