_BC_ Ну так в XMM регистров не хватало. Так как при раскрутке циклов 4 регистра фактически представляли из себя один логический а другии 4 другой. то фактически мы имели только 2 регистра с которыми не разбижишься. Поэтому увелечение XMM регистров оправданно. Что косается увелечение базовых регистров, это позволит более свободно заниматься оптимизацией. В том то и дело, что SIMD инструкции не используются(мало) для обычных операций( работы со строками, массивами и др). А обычные операции не дают, той скорости которую дают MMX и SSEx. По той причине что их регистры имееют размер в 2(4) раза меньше. И тем самым нагрузка на память, так как там шина данных больше 32 не достигает своей полной нагрузки.
Скажем так 64бита это не революция... Это эволюция. Я бы сказал 2х32... Это как оптимизация - разворачивание цикла А в принципе, почти всё что можно было оптимизировать, было оптимизированно под ММХ и иже с ним ХММ... Те же строковые команды...см. мануалы Агнера Фога. См. архитектурные особенности Conroe (fcenter.ru) - обработка 128 бит за такт(!) в ХММ, раньше за 2. Просто производители подтянули возможности основных регистров до ХММ.
Лучше бы регистров общего назначения сделали побольше. Было 8, стало 16, да еще 8 xmm-ок накинули (да и то все это только в 64-битном PM, который не все используют). Вот если бы их сделали например 128 да еще объединили бы в банки для быстрой смены контекстов - это бы дало простор для оптимизаций, а тупое оперирование 64 и 128-битными числами - сомнительное достоинство, учитывая, что выравнивание увеличится, размеры кода и данных тоже, требования к памяти опять возрастут, и все это съест часть роста производительности (а кое-где, на "однобайтовых" алгоритмах так и вообще все сильно ухудшится).
хотелось бы послушать демомейкеров но только тех кто пишет на асме. я думаю они скажут РУЛЕЗЗ по поводу 64бит регистров а по поводу дополнительных регистров они вообще должны танцевать от счастья.