Существуют ли какие-либо реализации языка C без дополнения до двух?

Как мы все, несомненно, знаем, стандарт ISO C ( и C ++, я думаю, хотя меня больше интересует сторона C) позволяет три основных представления чисел со знаком:

  • дополнение до двух;
  • дополнение; а также
  • знак / величина.

В статье Википедии говорится, что знак / величина используется на IBM 7090 с 60-х годов, а их дополнение используется в PDP-1, CDC 160A и UNIVAC 1100, все из которых также относятся к 60-м годам.

Существуют ли какие-либо другие реализации C (или базового оборудования) с этими альтернативными представлениями, появившиеся немного позже, чем пятьдесят лет назад (и какие они)?

Кажется немного расточительным оставлять что-то в стандарте для машин, которых больше нет.


c language-lawyer iso negative-number representation
person paxdiablo    schedule 05.09.2012    source источник
comment
Да, кто-то знает, что реализации, не являющиеся дополнением до двух, могут рассматриваться как ответ? :-)   -  person Kerrek SB    schedule 05.09.2012
comment
@KerrekSB: Только если вы подтвердите это доказательствами ... :-)   -  person R.. GitHub STOP HELPING ICE    schedule 05.09.2012
comment
@KerrekSB: обновил вопрос, и что они такое, чтобы сделать спорным :-)   -  person paxdiablo    schedule 05.09.2012
comment
Обратите внимание, что удаление не-2-дополнительных из стандарта полностью испортит мою стандартную реакцию на все, что вы думаете об этой беспорядочной феерии? вопросы, которые должны быстро подтвердить, что они не работают для отрицательных чисел с дополнением до единиц. Таким образом, я либо категорически против этого, либо категорически за, но я не уверен, что именно.   -  person Steve Jessop    schedule 05.09.2012
comment
См. Экзотические архитектуры, о которых заботится стандартный комитет   -  person Bo Persson    schedule 05.09.2012
comment
@SteveJessop С сожалением сообщаю вам, что самый последний черновик, следующий за документом N2412. , теперь требуется представление с дополнением до двух.   -  person texdr.aft    schedule 22.03.2021

Ответы (2)


arrow_upward
35
arrow_downward

Самый последний пример, который я могу найти, - это серия UNISYS 2200 на основе UNIVAC, с арифметикой с дополнением до единицы. Различные модели производились в период с 1986 по 1997 год, но ОС все еще находилась в активной разработке до 2015 года . У них также был компилятор C, как показано здесь.

Кажется вероятным, что они все еще могут использоваться сегодня.

person Mike Seymour    schedule 05.09.2012
comment
Ради интереса, для чего был Unisys 2200 для? Замена изношенных Univac с критически важными устаревшими приложениями или есть новые разработки? - person Steve Jessop; 05.09.2012
comment
Еще в прошлом году Unisys предложила оборудование под управлением OS2200. (2011). - person Bo Persson; 05.09.2012
comment
Согласно Википедии, последняя версия OS 2200 выпущена в 2010 году. - person Fred Foo; 05.09.2012
comment
Хорошая находка. Я провел дополнительное исследование, чтобы обнаружить, что у него действительно есть компилятор C, и скорректировал ваш ответ в соответствии с ним. Надеюсь, ты не против. Думаю, мы все-таки не будем подавать в INCITS петиции, чтобы они посоветовали ISO по поводу удаления :-) - person paxdiablo; 05.09.2012
comment
Компилятор C OS 2200, по-видимому, не соответствует стандартам в своем режиме дополнения. Максимальное значение без знака (UINT_MAX) равно 2^N-2 not 2^N-1. Похоже, это сделано для того, чтобы 0x3FFFF или минус ноль не было допустимым значением, когда вы приводите подписанное к беззнаковому int без изменения битового шаблона. (C99 и C11, то есть, он может соответствовать C89, но только нет закона против него, довольно очевидно, что ожидается от неподписанного быть. ) - person user3710044; 18.04.2015
comment
Жаль, что стандарт не дает возможности сказать, что в этом контексте я хочу, чтобы система либо вела себя как X-машина, либо отказывалась от компиляции, если она не может. Такой дизайн позволил бы такой системе, как OS2200, продолжать поддерживать свою существующую кодовую базу, но также сделал бы возможным запускать код для других машин, например, используя unsigned внутри для всех целочисленных типов, но имея int x,y; long z; ... if (x > y) z=x; машинный код, эквивалентный if ((x + 0x8000u) > (y + 0x8000u)) z = (x + 0x8000u)-0x8000ul, и генерируя аналогичный код для сдвигов вправо и делений. - person supercat; 30.04.2015
comment
Даже если компилятор был обновлен в 2015 году, он, похоже, не соответствует ни одному стандарту, предшествующему C89; среди прочего, он не имеет беззнакового типа длиной более 36 бит. - person supercat; 10.11.2016
comment
@ user3710044 Обратите внимание, что стандарт C допускает дополнение до единиц. Однако максимальное значение без знака по-прежнему недопустимо. - person martinkunev; 08.07.2018

arrow_upward
5
arrow_downward

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

Возможно, лучший способ собрать доказательства - это поискать противоречащие друг другу требования и другие явные ошибки в стандарте, связанным с системами без двойного дополнения. Если такая реализация никогда не создавалась, вероятно, в спецификации есть упущения, которые станут очевидными, когда кто-то действительно попытается ее создать.

person R.. GitHub STOP HELPING ICE    schedule 05.09.2012
comment
Или, чтобы сделать это тщательно: напишите виртуальную машину с минимальным байт-кодом, которая использует дополнение до единиц и / или знаковую величину. Реализуйте для него бэкэнд GCC или LLVM, если любой из них имеет номинальную поддержку для этого, или полную реализацию C, если нет. Это и отвечает на вопрос (да, теперь я знаю о реализации, отличной от двух дополнений), и дает возможность подавать отчеты о рассматриваемых дефектах, если в стандарте есть упущения. Если какой-либо из дефектов является критическим, то это боеприпасы, требующие дополнения 2 в следующем стандарте. - person Steve Jessop; 05.09.2012
comment
@SteveJessop: это крутой подход, но это может потребовать немного больше работы, чем обычно требуется для ответа на SO-вопрос ;-) - person Joachim Sauer; 05.09.2012
comment
@JoachimSauer: Я признаю, что лично меня это не беспокоит. - person Steve Jessop; 05.09.2012
comment
Стандарт номинально допускает существование отрицательного нуля для таких реализаций, но я, кажется, помню, что было какое-то забавное взаимодействие побитового not и другого оператора, которое сделало результирующие требования чрезвычайно дорогостоящими для удовлетворения, если не невозможными ... может найти его снова, этого было бы недостаточно, чтобы убить недвоичное дополнение, но этого могло бы быть достаточно, чтобы уничтожить допущение для отрицательного нуля. - person R.. GitHub STOP HELPING ICE; 05.09.2012
comment
Стандарт IIRC предполагает, что если ваше оборудование имеет отрицательный 0, но вы не хотите поддерживать его должным образом в C, вы ничего не можете сделать. Если у вас официально нет отрицательного 0, то битовые операции, которые генерируют это представление, имеют UB. Так что возвращение представления ловушки, которое в основном ведет себя как 0, но не совсем правильно, нормально. Что ж, соответствует. Программист, который случайно напишет ~i без проверки (i != 0) && (i != INT_MAX), может подумать, что это не нормально. Я бы предпочел убрать требование о применении битовых операций к подписанным типам, если мы того пожелаем ;-) - person Steve Jessop; 05.09.2012
comment
@SteveJessop: удачи в написании бэкэнда GCC для машины без двух дополнений. Вам также придется переписать большую часть среднего уровня, и если вы хотите запустить его изначально на этой цели, тогда весь компилятор, вероятно, потребует однократного просмотра (не говоря уже об остальной части ОС). - person ams; 05.09.2012
comment
@ams: у моей цели нет ОС, это просто игрушечный интерпретатор байт-кода. Но если GCC предполагает дополнение 2, то конечно, это не годится для моего гипотетического проекта. - person Steve Jessop; 05.09.2012
comment
Я предполагаю, что GCC предполагает как минимум два дополнения, так и 8-битные байты. Что ж, вместо того, чтобы предполагать, я бы просто сказал, что определяет, поскольку определение этих концепций зависит от компилятора. Даже на машине, которая была предназначена для выполнения знака / магнита или дополнения единиц, компилятор может легко выбрать предоставление среды дополнения до двух, просто используя беззнаковые арифметические инструкции вместо подписанных ... - person R.. GitHub STOP HELPING ICE; 05.09.2012
comment
В стандарте для реальных машин достаточно несоответствий, поэтому такой подход ни на что не указывает ... - person M.M; 03.08.2015
comment
@MattMcNabb: Цитата? Мы все знаем о незначительных вещах, в которых существует общий консенсус относительно предполагаемого значения или, по крайней мере, того, как компиляторы реального мира должны его интерпретировать. Я подозреваю, что несоответствия будут намного более привлекательными для не-двоичного дополнения и возникнут сразу же, когда вы попытаетесь выработать поведение для stdio и строковых функций. - person R.. GitHub STOP HELPING ICE; 03.08.2015