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

Во время перехода от 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 бита?
8
задан Matt Joiner 24 July 2010 в 15:43
поделиться

2 ответа

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

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

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

WORD и DWORD уродливы, и их следует избегать. Если API вынуждает вас использовать их, замените DWORD на DWORD_PTR, когда вы имеете дело с ... ну, указателями. ИМХО, там никогда не было правильного использования (D) WORD.

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

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

6
ответ дан 5 December 2019 в 17:33
поделиться

Вместо того чтобы рассматривать это как то, что 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-элементов. Просто существуют фундаментальные различия в отношении числовых величин к реалиям физического мира, человеческого разума и т.д.

4
ответ дан 5 December 2019 в 17:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: