уберут ли когда-то поддержку 32-битного режима из процессоров архитектуры x86_64?

А легаси? Если ты не играешь в игры это ещё не значит, что никто не играет.

Не уберут.
Внезапно, но до сих пор остались 16-ти битные инструкции.
Так что теоретически ты на своём ультра- супер- мега- новом Core i7 можешь загрузить MS DOS 6.22
Правда хрен ты найдёшь сейчас свежую материнку с поддержкой флоппов, но это уже другой вопрос.

А зачем? 64-бита - это, по-сути, один бит в кодировке IA32. ISA (instruction set architecture) до сих пор 16-битные регистровые команды поддерживает. Да и 8-битные тоже.

И внутри проца тоже не шибко много дополнительных гейтов нужно, чтобы 32-битный режим тянуть.

Что, прямо так и написано: typedef long long time_t?

Не, там sizeof(time_t) для 32-битных 4байта, для 64-х - 8
Во всяком случае для 2.20 это так.

А я на x86_64 собирал, ЕМНИП. Ассемблер там не только 32х-битный, но можно при компиляции вообще вместо него аппаратнонезависимую реализацию использовать.

UPD: А, не это я про dgen.

sizeof(time_t) для 32-битных 4байта

Так в этом и проблема

Не, там sizeof(time_t) для 32-битных 4байта, для 64-х - 8

У меня для тебя плохие новости: для x86_64 sizeof(time_t) всегда был 8, т. к. time_t определен как long.

Как только перепишут игры все на amd64.

Зачем флоппи, если можно грузиться с чего угодно и использовать ram-диск? На свежих материнках загружал MS-DOS, брат жив.

Там зачастую 32-bit only программы, как и на венде.

Это не надолго. Скоро эпол зафорсит 64 бита и в приложениях для osx, как это сделал с приложениями для ios.

просто пишут YYYY-MM-DD HH:mm:SS

Хранить 64 бита вместо строки дешевле. Поиск по 64 битам дешевле, выборка дешевле, сравнение дешевле.

Меня вот больше беспокоят завершающиеся нулевым байтом строки.

Тогда это было разумно. Тратим один байт вместо нескольких на хранение длины строки. А когда строки короткие и их много, то экономия получается приличная. Единственный минус - это вычисление длины строки. Но при сравнении или копировании строк вычислять длину нет необходимости.

Да и вывод дешевле. Часовые пояса никто не отменял. А это значит, что при выводе тупо вывести строку не получится - придётся распарсить её, прибавить/вычесть нужное количество часов и преобразовать обратно.

А еще в трансмете работал линус торвальдс. Но все передовые идеи на тот момент оказались ненужными и трансмета сдохла.

Это ещё не всё. В том же Pascal поставили один байт для хранения длины - и что же получили? Кучу проблем и извращений, когда надо работать со строками длиннее 255 символов. Так что длину строки надо хранить как минимум в 16 битах, а лучше вообще в 32. Ведь строка может быть загруженным текстовым файлом, который нужно распарсить (зачем использовать для этого самописные функции, когда есть стандартные библиотечные строковые), а текстовые файлы длиннее 64КБ не такая уж редкость. Так что null-terminated строки это как раз таки пример удачного решения, когда не пришлось ничего менять даже когда компьютеры смогли обрабатывать строки из миллионов символов, которые раньше казались ненужными. И не придётся ничего менять даже когда мощности компьютеров позволят свободно обрабатывать многогигабайтные строковые данные. А вот на 64-битное дату-время пожмотились и получили проблемы.

Стандартизация вообще вещь такая, что надо учитывать всё. Нельзя говорить «никто не будет пользоваться нашей программой в 2038 году», «никому не нужны строки длиннее 256 байт», «в Интернете никогда не будет больше 4 миллиардов компьютеров». Надо сразу делать запас на несколько порядков (хороший пример - IPv6, которые не кончатся даже если мы начнём колонизировать другие звёздные системы и при этом будем применять единую адресацию). Ведь небольшое снижение производительности в будущем компенсируют (например, современные процессоры делают 64-битную арифметику с такой же скоростью, как и 32-битную), а вот за необходимость переписывать с нуля весь софт - проклянут.

А зачем тебе флопы ?

На длину тоже можно тратить 1 байт. Да, будет не больше 256 символов длиной. Отвечая и на сообщения ниже:
А кто сказал что строковый тип должен быть одинаковым во всех случаях, и в ядре, и в текстовом редакторе? Я думаю в случаях, где ошибки переполнения и производительность особенно важны, там не слишком длинные строки.

Для разных случаев можно делать разное количество байт. Есть разные типы int.

А как же совместимость с dos?

Вот кстати, все эти long long это точно надо выкинуть, а оставить int и int8_t, int16_t, int32_t, int64_t, и соотв uint*, чтобы не вспоминать каждый раз

http://storage4.static.itmages.ru/i/15/0511/h_1431352452_1518848_afb298befa.png Кутэ оболгали!

UPD: не совсем, некоторые реально x64 называютюсчюяювючв.......вя....

Так что длину строки надо хранить как минимум в 16 битах, а лучше вообще в 32.

На на x86_64 вообще в 64 битах.

Так что null-terminated строки это как раз таки пример удачного решения

Да, только использовать их нужно с умом. К примеру сделать обертку вокруг strcat, если хочется склеивать строки.

По остальному согласен.

На длину тоже можно тратить 1 байт. Да, будет не больше 256 символов длиной.

А 640К хватит всем.

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

Там используют свои реализации и свои методы работы со строками.

Чтобы ъ-канонiчно.

Три страницы, а никто не сказал ещё, что игорь не нужен.

По сабжу — обратная совместимость рулит, даже 16-разрядного бинарного софта ещё навалом, не говоря уж о 32-разрядном; но сырцефашистам этого, конечно, не понять. amd64 в своё время победил IA-64 именно за счёт обратной совместимости. В принципе, обратную совместимость можно будет закопать, когда любая кофемолка сможет прозрачно эмулировать хотя бы 32-разрядный не совместимый с ней CISC, а лучше 64-разрядный. Замкнутый круг вряд ли будет продолжаться, потому как amd64 хватит на десятки лет, и уже сейчас большая часть софта пишется на платформонезависимых технологиях. Пока — очень и очень рано (чтобы оценить весь масштаб трагедии, попробуйте на неслабеньком армодевайсе запустить под Bochs что-нибудь потяжелее Windows 98 четвёртой слаки). amd64 же обратно совместим by design; большая часть инструкций наросла слоями, не заменяя компоненты более низких разрядностей, что позволяет невозбранно работать с однобайтовыми переменными, например. В принципе, можно выкинуть 16-bit-only и 32-bit-only штуки типа всяких реальных режимов, но смысл? это пшик.

Милчеловек, скажи: как пробросить USB-порт в виртуалку, чтобы хост его вообще не касался? Я очкую так мобилу в прошивочном режиме подключать; неизвестно, как она отреагирует хотя бы на то, что её два раза спрашивают, кто она такая.

Что мешает сделать несколько строковых типов разной предельной длины, как это сделано во многих СУБД, например? Да, придётся иногда конвертировать между ними, но по сравнению с профитом в потреблении памяти это фигня, особенно учитывая, что mutable-строки — зло, а всякие торможабы и так гоняют постоянно переменные туда-сюда для дефрагментации.

Я пробрасывал и прошивал ~100 телефонов разных марок, ничего с ними не случилось. Машина — VNWare.

32-bit only юзерспейсных программ я не встречал.

Их огромное количество. В том числе игр.

Если на то пошло, в линуксе есть вещип окруче. Например, SIP. И что?

Ты уж определись - про линукс ведёшь речь или про всё и сразу.

У меня есть работающий компьютер на Crusoe. И что с того?

А чем твои кучи говна лучше куч говна от маркетологов AMD и Intel?

Спешу тебя огорчить