> в булочную за углом сбегать.

Ну если тебе только в булочную, типа старта vim и тетриса, а в другой город совсем никак и никогда - ок, тогда да, может тебе 64 бита и излишни. Это однако не отменяет того факта что современные процы напрочь 64-битные и 64 бита становятся дефолтной архитектурой, с выносом 32 битов в легаси. Примерно как сейчас почти никому не приходит в бошку писать 16-битный код под х86.

> нет, задолбало пихание 64-битности во все дыры.

Сдох ваш бобик. На серверах - давно. А теперь и на десктопах, ибо объем памяти на типовом десктопнике и даже многих ноутах уж давно перевалил за 4Гб. Поэтому 32-битный х86 обречен стать легаси. И становится. Те же криптографы при дизайне новых алгоритмов стали часто ориентироваться на эффективность алгоритмов на 64-битных регистрах. А на 32-битных - по остаточному принципу, т.е. компилер конечно как-то разопрется проделать 64-битные вычисления оптом и на полутора куцых 32-битных регистрах. Но по скорости просядет. В несколько раз. Вот такая нынче правда жизни.

> и да, x32 придумывали не просто так, например.

Как по мне все это х32 - страдание фигней. Судя по тому как на х32 все дружно положили кроме пары гентушников - не один я так считаю. Вообще, нагревать себя на плюсы 64 битов, коли они уж есть - дурь несусветная.

> потому что большинству софта не нужно больше нескольких гигов RAM,

Даже если софт не вгружает несколько гигз данных в RAM (хотя я не вижу почему мне например должно быть нельзя вкатить в графический редактор реально большой файл, etc если физически памяти хватает) - есть еще например memory-mapped файлы. И совсем не комильфо их обрубать величиной несколько гигз.

> а на указатель всё равно будь любезен потратить 64 бита.

За счет относительной адресации - ряд сущностей вполне можно адресовать относительным смещением, скостив число указателей. А когда программа не может адресовать всю доступную память по человечески - это defective by design, извините. Если потребление памяти какой-то программе надо жестко залимитировать, в системах нынче есть более приличные рукоятки.

> а чо, не жалко, памяти же много! где-то я такое уже видел…

Ну как бы соотношение efforts/results должно быть разумное. Основной объем памяти в системах обычно занят отнюдь не указателями, так что экономия плюс-минус пары метров на всю систему при том что это будет достаточно глобально икаться там и тут, в виде невозможности отпроцессить вон тот большой кус данных вгрузив в память или обкоцывания mmaped файлов - да нафиг надо такие извращения.

> памяти досыпьте, не жмотьтесь!»

На самом деле, 64-битные программы кушают не сильно больше 32-битных.

> я на своих 4gb так и работаю, кстати. при этом у меня
> запущена куча софта, собирается немало кода с кучей шаблонов и CTFE…
> и «в среднем по больнице» где-то гиг памяти свободен.

А я вот тут активно пересобираю линевый кернель и осознал все плюсы хренадцати гигз. Более-менее разлапистый конфиг с дебажной информацией может в сумме генерить сотни мегз записей на диск и читать чуть ли не гигабайтами. И знаешь, хорошо все-таки когда при этом cache hit случается и не вымывается какое-нибудь оглавление разлапистой иерархии. Так даже механический диск может работать с "около-SSDшной" скоростью большую часть времени.

> от этого раздуваются структуры данных и сколько новых матюгов они от
> этого изобрели.

Хз, знаю энное количество игроделов и на моей памяти никто из них не высказывал никаких особых претензий к х86-64. А основной объем у них занимают отнюдь не указатели, а ресурсы, пардон. Вес которых вообще не зависит от битности системы.

> да и не только игроделы, в принципе…

Да, да, расскажи нам как любители mmaped файлов относятся к идее обрубить виртуальное пространство. Слушаю с нетерпением.

> классно тебе. и раздувания структур данных тоже не заметишь.

Ну да, как-то так. Просто потому что указатели явно не занимают существенный процент памяти системы. А у какого-нибудь дискового кэша основной статьей расхода будут сами кэшированные данные, etc.

> а вот многие другие — замечают. поэтому, например, попытались придумать x32.

А mmaped файлы там тоже обрублены до 2^32, да? Ну или как адресовать больше при 32-битных указателях?

> мусорятся влёт. и их надо или перезагружать, или сначала сохранять, а
> потом перезагружать. привет, неявный стек!

Регистры мусорятся, но еще, знаешь ли, старые результаты вычислений иногда перестают быть нужными. И тогда регистры можно реюзать без сохранения и перезагрузки, просто снеся содержимое которое больше нигде использоваться не будет. И чем регистров больше - тем чаще можно будет все обтяпать в этих регистрах, не занимаясь их перегрузкой. Так что я всецело поддерживаю идею донавесить регистров и расширить их битность. Хуже не станет, а вот лучше - запросто.

>> А у x86 даже и убрать нельзя - изначально нету.
> есть, есть.

Меньше чем у x86-64.

> хотя их несимметричность раздражает.

И битность меньше. В общем нафиг. У...щнее х86 по архитектуре я знаю лишь 1 систему команд - Microchip PIC. Но этот гаденыш маленький, ему еще хоть как-то простительно. Правда я этот тип гаденышей по этой причине программить никогда не буду.

> ага. умные современные компиляторы тоже не занимаются таким: они просто выделяют стековый
> фрэйм и запихивают туда данные при помощи mov.

А это кто как. Лениво лезть в асмовые листинги, но насколько я помню, ABI с передачей в регистрах вполне активно пользуются.

> реальный выигрыш — это какая-то, например, математика по массивам с кучей измерений.

Или криптография например. Хеширование, шифрование. Обработка мультимедийных данных. А то что ты упоминаешь, нынче модно выгружать на GPU. Там обычно невъ....ное количество регистров, целыми блоками, широких по битности. Ряд команд могут за 1 присест сделать одинаковые трансформации над субкомпонентами регистров, рассмотрев регистр не как 1 широкое число а как пачку более коротких чисел (особо массовый вариант SIMD). И блоков выполнения стоит 100500 штук. Потому оно 3D и долбит с такой скоростью... но если там вдруг не 3D а какие-то иные данные, оно совсем не возражает и их так же раздолбить, ALUшкам не принципиально что там. По поводу чего ускорение на GPU и является модной темой. Многие алгоритмы там вставляют системному процессору в десятки раз. Но ececution flow control там обычно слабый - это не general purpose проц.

> и то во многих случаях компилятор «раскрутит» циклы и будет использовать
> один-два регистра для адресации.

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

> это не отменяет костыльности.

Мир вообще не идеален. Своп на HDD вон тоже дикий костыль. Но некоторые до сих пор пользуются.

> конечно. эти костыли с древних времён тянутся, когда вообще всё печально было.

Ну вон у некоторых GPU насколько я понял регистры == локальная память/кэш, измеряется в килобайтах. Правда как ты заметил, компилер справится и без таких наворотов и не так уж и сильно продует. А програмер задолбается трекать тысячи регистров и может проcpaть компилеру в глобальной оптимизации.

> нечто похожее в 6502, кстати.

Не сильно похожее. Мнемоника команд интелообразная. Называлось сие 80C166 (C167...169 etc). Какая-то вполне самобытная архитектура от инфиньoна/cимeнса (не знаю уж, лицензировали они ее у кого или сами сделали).

> не совсем, но адресовать первые 256 байтов там достаточно удобно,
> их и использовали как «дополнительные регистры».

Я в курсе что есть 6502 и имею отметить что невозможность использовать часть режимов адресации на части памяти - анноит, а "дополнительные регистры" по возможностям не идут ни в какое сравнение с аккумулятором. Если делать 6502 по человечески, на современном уровне - получится ARM.

> что в регистрах мусор и весело загружать их заново. чем больше
> регистров — тем больше и загружать.

Не так уж и много. Локальных регистров под счет все-таки ограниченное количество.

> я ж говорю: выигрыш в основном в том, что для компилятора выражений
> доступно больше «быстрых хранилищ»,

Да и при программировании вручную как-то удобнее просто реализовать алгоритм чем мудoxaться с техническими перегрузками по причине "регистров не хватило". И вообще, попробовав использовать какую-нибудь логичную и симметричную систему команд типа ARMовской, да с кучей регистров - от х86 будет тошнить и это не лечится. Уроды типа х86 в основном по душе тем кто слаще морковки ничего не ел. В х86-64 это стало хоть немного походить на нормальные процессоры.

> сброс регистров на узле ветвления. и если посмотреть на большинство выражений
> в программах — получится, что там регистров-то надо совсем немного.

Весьма зависит от программ и чего они хотели. Какой-нибудь алгоритм шифрования или хэширования может запросто интенсивно ворочать пачку 64-битных переменных. При этом x86 разумеется будет в пролете с его полутора куцыми 32-битными регистрами. Это же касается и всяких кодеков и прочих (этим правда больше в кассу SIMD, и тут гарантированный SSE2 оказывается очень кстати).

> ну да: прикрыли голову — ноги голые.

Ну, блин, приди и покажи этим лохам как надо процы делать. Я теперь на это по крайней мере могу смотреть не сблевывая прямо сразу.