LP64, LLP64 и переход IL32

Question

Во время перехода от 16 до 32 бит в 80-х годах int был либо 16, либо 32 бит. Используя текущую номенклатуру номенклатуры 64 бит, я понимаю, что было довольно распространенное распространение машин ILP32 и LP32. В то время я полагал, что было понятно, что int всегда будет следовать за регистрами или шириной указателя для любой заданной архитектуры и что long останется 32 бит.

Быстрая перемотка вперед 25 лет, я вижу, что LP64 довольно распространен, но пока я не столкнулся с 64-битными платформами [мое открытие настольного Linux в 2007 году :)], я всегда ожидал, что IP64 станет следующим логическим шагом.

1. Было ли это (LP64) ожидаемой эволюцией для 64-битных?
   • Каким образом отношения char <= short <= int <= long вписываются в эту новую схему фиксации целочисленного типа на каждую платформу, которую мы оставляем?
   • Как эти схемы перехода относятся к использованию (на ваш выбор {l,u}case) WORD/DWORD на разных платформах?
   • Некоторые области Windows по-прежнему содержат INT формы, которые являются 16-битными. Будет ли Windows вырастать из LLP64 или уже слишком поздно?
   • Почему было int выбрано для того, чтобы быть оставленным позади этого времени, в отличие от во время 32-битного перехода?

Answer 1

Как я вижу, это то, что Windows, является чудаком в целом переходе x64. Но, отложив это, C или C++ никогда не определяли фиксированные длины интегральных типов. Я считаю, что все int/long/pointer вполне понятно, если вы посмотрите на это следующим образом:

int: в основном 32 бита длиной (Linux, Mac и Windows) long: 64 бит на Mac и Linux, 32 на Окна долго долго: 64-разрядные на Mac, Linux и Windows x64 (и) intptr_t: точная длина указателя (32 на 32-битной, 64 на 64-разрядных системах)

Я использую только символ в контексте из строк и никогда не использовать короткие, так как до тех пор, пока int на большинстве настольных систем.

WORD and DWORD являются уродливыми, и их следует избегать. Если API заставляет вас использовать их, замените DWORD на DWORD_PTR, когда вы имеете дело с ... ну, указатели. Никогда не было правильно использовать (D) WORD там, в первую очередь, IMHO.

Я не думаю, что Windows изменит свое решение, когда-либо. Слишком много неприятностей уже

Почему было оставлено позади? Почему Венера вращается в противоположном направлении? Ответ на первый вопрос найден here (я считаю), второй немного сложнее;)

Answer 2

Вместо того, чтобы смотреть на это как int «оставлено позади», я бы сказал, что вы должны смотреть на него в терминах из-за того, что вы не можете оставить какой-либо тип размера, который может потребоваться. Я предполагаю, что компиляторы могли бы определить int32_t с точки зрения внутреннего типа __int32_t, но с C99, который еще не получил широкого распространения, было бы большой проблемой для приложений, которые могли бы обойти отсутствующие определения int32_t, когда их системы сборки не смогли найти 32-разрядный тип среди стандартных типов.И наличие 32-разрядного типа имеет значение, независимо от того, каков ваш собственный размер слова (например, это единственный правильный тип для кодовых значений Unicode).

По этой же причине было бы невозможно сделать short 32-разрядным и int 64-разрядным: 16-разрядный тип необходим для многих вещей, при этом возникает первая обработка звука. (Не говоря уже о уродливой овации UTF-16 в Windows/Java)

Действительно, я не думаю, что переходы от 16 до 32 бит и 32-к-64-бит абсолютно сопоставимы. Оставив за собой 16-бит, он оставил после себя систему, в которой большинство чисел, встречающихся в обычной повседневной жизни, не соответствовало бы базовому типу и там, где хаки, такие как «дальние» указатели, должны были использоваться для работы с нетривиальными наборами данных. С другой стороны, большинство приложений имеют минимальную потребность в 64-битных типах. Большие денежные показатели, размеры/смещения файлов мультимедиа, позиции диска, высококачественные базы данных, доступ к крупным файлам с памятью и т. Д. - это некоторые специализированные приложения, которые приходят на ум, но нет оснований думать, что текстовый процессор когда-либо понадобится миллиарды символов или что веб-страница когда-либо понадобится миллиарды элементов html. Существуют просто принципиальные различия в соотношении числовых величин с реальностями физического мира, человеческого разума и т. Д.