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

Question

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

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

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

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

572 2

c history architecture

2 ответов:

Comments

Ничего не найдено.

rubenvb · Accepted Answer · 2010-07-24 18:57:51

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

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

I используйте только char в контексте строк и никогда не используйте short, так как он так же длинен, как int в большинстве настольных систем.

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

Я не думаю, что Windows изменит это решение, когда-либо. Уже слишком много хлопот

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

R.. · Accepted Answer · 2010-07-24 19:38:24

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

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

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