Список платформ, поддерживаемых стандартом C

Ответ 1

Недавно я работал в компании, которая до сих пор использовала версию PDP-10 и порт GCC для этой платформы. В 10, которые мы использовали, были перечислены несколько атрибутов:

• Целые числа не равны 32 или 64 битам шириной 36 бит.
• Для некоторых представлений используются биты заполнения. Для расширенных целых чисел (например, длинного длинного типа) базовое представление было 72 бит, в котором каждый из 36-разрядных слов имел знаковый бит.

В дополнение к вышеуказанным необычным атрибутам возникла проблема, заключавшаяся в том, что в машине было несколько различных механизмов адресации байтов. Байты шириной в диапазоне 6-12 бит могут быть решены с помощью специальных битов в самом адресе, который указывает, какая ширина и выравнивание слов использовались. Для представления char * можно было бы использовать представление, которое предназначалось бы для 8-битных байтов, все из которых были выровнены по левому краю в слове, оставив по 4 бита в каждом 36-битном слове, которые вообще не были адресованы. В качестве альтернативы можно использовать 9-битные байты, которые равномерно поместились бы в 36-битное слово. У обоих таких подходов были проблемы с переносимостью, но в то время, когда я ушел, было разумнее использовать 8-битные байты из-за взаимодействия с сетями TCP/IP и стандартными устройствами, которые часто думают в терминах 16, 24 или 32 -битные поля, которые также имеют базовую структуру 8-битных байтов.

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

Ответ 2

Следует отметить, что вы не можете полагаться на поведение undefined даже на часто используемых платформах, потому что современные оптимизирующие компиляторы выполняют программные преобразования, которые сохраняют только определенное поведение.

В частности, вы не можете полагаться на две арифметические дополнения, которые дают вам INT_MAX+1 == INT_MIN. Например, gcc 4.6.0 оптимизирует следующее в бесконечном цикле:

#include <stdio.h>
int main() {
     int i = 0;
     while (i++ >= 0)
          puts(".");
     return 0;
}

РЕДАКТИРОВАТЬ: Смотрите здесь, чтобы узнать больше о подписанных переполнениях и оптимизации GCC.

Ответ 3

Около десяти лет назад нам пришлось перенести нашу встроенную базу данных C в процессор DSP, который стал основным процессором стереосистемы. Это была 24-битная машина, худшая: sizeof(char) == sizeof(int) == sizeof(void*) == 1, которая была 24 бит. Мы назвали ветку, которая рассматривала этот порт "24-битный ад".

С тех пор мы портировали нашу библиотеку на многие платформы, но ни одна такая странная. Они все еще могут быть там (дешевые 24-битные чипы DSP еще дешевле), которые можно найти в недорогих устройствах, где простота программирования является далекой секундой от низкой спецификации материалов (BOM). Подумайте об этом, я думаю, что мы столкнулись с машиной, где правый сдвиг целого числа без знака необязательно вставлял нулевые биты. Тем не менее, высокостандартные арифметические правила на платформе гарантируют сложный, подверженный ошибкам перенос программного обеспечения на него, что резко увеличивает затраты на разработку программного обеспечения. В какой-то момент преобладают здравомыслие и соблюдаются стандарты.

Я подозреваю, что большая мотивация наличия этих правил на C99 - это их присутствие на C89 и более ранние итерации языка. Не забывайте, что когда C был изобретен, компьютеры были намного более разнообразны, чем сегодня. Конструкции процессоров "бит-срез" были доступны там, где вы могли добавить столько бит, сколько захотите, только добавив фишки. А до C вам приходилось кодировать на ассемблере или беспокоиться о том, где именно в RAM будет находиться ваш код и т.д.

C стал резким шагом вперед в плане переносимости, но он должен был загонять разнообразные системы, а значит, и самые общие правила. Спустя 20 лет, когда появилась Java, у нее была история, которая позволила ей заявить, насколько велики примитивные типы, что делает все намного проще, если Java-выбор звучит.

Я знаю, что вы в основном спрашиваете о целых числах, но я столкнулся с какой-то странностью, когда дело доходит до указателей. Ранние компьютеры Macintosh имели 32-разрядные процессоры (Motorola 68000), но только 24-битные шины памяти. Таким образом, 0x00123456 и 0xFF123456 относятся к одной и той же ячейке памяти, потому что процессор отрубал верхние 8 бит при доступе к ОЗУ. Инженеры Apple использовали эти биты для хранения метаданных о памяти, на которую указывал указатель. Таким образом, при сопоставлении указателей сначала нужно было скрыть верхние биты. И не заставляйте меня начинать с сегментированных архитектур памяти в x86.:)

Поскольку мы обсуждаем эту тему, ознакомьтесь со стандартом кодирования MISRA, который предпочитают производители автомобилей, которые нуждаются в максимальной переносимости и безопасности. Также посмотрите на Hacker Delight Генри С. Уоррена, в котором есть тонны полезных бит-трюков.

Ответ 4

Мои два цента. Пожалуйста, не винитесь сильно, это из моего опыта, я не теоретик:

• не 2 дополнения

Все существующие ЦП - это 2 дополнения

• целочисленная ширина не 32 бита или 64 бита

Есть также 8 и 16-битные архитектуры. 8-битный AVR MCU - хороший пример.

• некоторые целочисленные типы имеют биты дополнений

Я не знаю ни одной системы, которая целыми целями. Плавающие числа - это совсем другая история.

• Если вы работали над машиной с двумя дополнениями, битовая диаграмма с битом знака 1 и всеми битами нуля не является допустимым отрицательным числом
• целочисленное преобразование из подписанного в unsigned (и наоборот) не осуществляется путем дословного копирования битовых шаблонов
• правый сдвиг целого не является арифметическим сдвигом
• количество битов значения в неподписанном типе не является числом битов значения в соответствующем подписанном типе + 1
• преобразование из более широкого типа int в меньший тип не происходит путем усечения левых самых битов, которые не подходят

Все вышеперечисленное - ничего не известно, и я полагаю, что такой машины нет.

Ответ 5

Даже если эти машины являются древними, для PDP-8 все еще существует активное программирование сообщества, большинство, но не все используют симуляции: PDP-8 в качестве примера. И эта машина AFAIK использует 12-битные целые числа!

Ответ 6

Компилятор cc65 для Commodore C64, похоже, имел некоторое обновление уже в прошлом году.

Ответ 7

Старая пословица (я забыл атрибуцию) говорит, что

нет переносимого кода

Но только то, что есть некоторый код, который был перенесен.

Вы не должны заботиться о написании портативного кода, вам следует заботиться о написании кода, который будет легко переноситься на другие платформы.

Кроме того, использование только стандарта C дает вам не много полезных вещей. Стандарты Posix дают вам гораздо больше.