[онолитеги][процессросрач] Ближайшее будующее CPU

Опосредованное :)

> В частности, AVX расширяет изначально 128-битные регистры SSE до 256 бит. Новые 256-битные регистры обозначаются как ymm0-ymm15 (для 32-битной программы доступны только ymm0-ymm7); при этом 128-битные SSE регистры xmm0-xmm15 ссылаются на младшие 128 бит соответствующего AVX регистра.
прокоментируешь?
в битах не запутаешься?

в том, что ядро там все равно не 128-битное.

>в чём проблема?
в том что это по-прежнему 32/64? К.О.

Зачем же ядру быть 128 битным? Операций с «длинными» числами в коде мало, разумно не ломать совместимость.

затем что бы быть 128-ми битным!
а зачем было ломать для 16-32-64???

Ну давай сделаем новый набор SSE-18, где инструкции будут работать сразу с 512 битами. Проц от этого 512-битным не станет.

>это по-прежнему 32/64

Нет, разрядность поддерживается аппаратно, и на корках 128bit выполняются за =< один такт.

Ничего не сломали. Дос работает.

о_О???
у меня 128-битный проц!
я вас разочарую - в будущем всё то же гавно (

>затем что бы быть 128-ми битным!

Травы-то отсыпь %)

http://www.linux.org.ru/jump-message.jsp?msgid=5282913&cid=5283435

Лучше б вместе собрались и сделали универсальный сокет, который был бы совместим и с амд и с инетлевыми процессорами.
Есть же PCI-X и т.п.

Читай целиком.

да читал уже
только от того сколько раз я прочитал битность проца/оси от этого не изменится
короче игнорь, а то спровоцирую и тебя на пруфы-тесты-исследования %)

> разумно не ломать совместимость

надстройки над x86 стало быть городить разумно?

Операции с числами >32bit в коде редки, без учёта указателей(адресация).

64bit - вообще практически не встречаются.

Смысла делать ядро более дорогим нет.

Здесь решает совместимость - часто нужный софт никто просто не пересоберёт под новую архитектуру, просто потому, что исходников нет, и компания-разработчик не осилит тянуть ещё одну архитектуру/вообще загнулась.

бррр
а кто запретил запускать 16-битный софт(например) на 32/64?
уж не лучше ли забить на единичные экземпляры, но получить профит от остального?

Профита нет, ибо.
Пруфом будут исходники любой проги )

а как там дела с x86-64, можно ли собрать полноценную программу, не использующую x86 инструкции вообще? или использование 64 разрядных регистров/инструкций исключительно опционально?

вот потому и говорю - пилить!
т.е. про «К.О. облажался» 4.2 :)

>можно ли собрать полноценную программу, не использующую x86 инструкции вообще?
gcc -march=native

Хотя, если внимательно читать мануал, можно сделать вывод, что x86_64 - это просто расширение x86.

В x64 коде часто используются 16bit регистры..

>-march=native
no way!

funtroll_loops.jpg

чо? о_О
кстати вспомнил про музычку fintroll %)

++

x86 по-тихоньку становится SoC. Это гуд.

Это как же оно греться-то будет и сколько будет стоить и жрать, если в один кристалл GF100 и i9 воткнуть?

Представь себе холодильник. А теперь представь, что это будет новый системный блок с офигенно здоровой системой охлаждения ))

Сколько неадеквата в теме, ужас.

рано обсуждать еще, толком не известно что там сделало АМД, с интелом понятно, просто засунули гпу на один кристал с цпу, а вот АМД сделало доступ гпу к кешу L3.

в старшей модели там аналог rhd 5670(480 sp точнее, чуть больше), в младшей - 54x0 (80 sp)

у интела там вообще примитивная интеграшка, которая только с rhd 54x0 потягаться сможет, и то не всегда.

никто gf100 на кристал с цпу пихать не будет разумеется.

а все от того что затычкой в данном случае становится пропускная способность памяти у встроенного контроллера памяти (думаете почему в core ix с интеграшкой, сама интеграшка с контроллером памяти вынесена на отдельный чип внутри процца, по сути тот же чипсет, тогда они еще не работали над проблемой этой - когда гпу сильно нагрузит память при работе с текстуированием, процу останется шишь да маленько, посему и не суют туда чтото мощное), интересно посмотреть как амд выкрутится.

Опять криокамеры потекли?

Dimka-Bo> Чудовищный бред.

С физической точки зрения - не бред. Обмен дырками - тоже обмен электронами.

anon_666> Ничего не сломали. Дос работает.

Не работает он в защищённом режиме. Не надо ля-ля.

x0r> а как там дела с x86-64, можно ли собрать полноценную программу, не использующую x86 инструкции вообще? или использование 64 разрядных регистров/инструкций исключительно опционально?

Опционально. Long mode подразделяется на два подрежима: возможность использования 64-разрядного расширения, и 32-разрядная совместимость. Так что без IA32 там дело не обходится.

pekmop1024> x86 по-тихоньку становится SoC. Это гуд.

Не становится. Уже есть SoC на ядрах x86. Например, Vortex86. И одноплатная платформа XCore86.

А что там на Athlon Neo? Точно так же - вынесена видеокарта в отдельный чип?

Вы про virtual 8086 mode? Он не нужен.

А dpmi как раз работает.

>Long mode подразделяется на два подрежима: возможность использования 64-разрядного расширения, и 32-разрядная совместимость.

Оба не могут использоваться в контексте одного процесса. Не в ту степь.

вендузятник детектед

>вендузятник детектед

Всё правильно, в игры я играю на виндусе, ибо нет желания устраивать пляски с вайном, но последнии две карты я сменил ради cuda/opencl, и GF100 куплю, когда подешевеет, исключительно ради Fermi.

Зачем объединять чипы? Всё просто: обмен электронами внутри одного чипа гораздо экономичнее, чем обмен теми же электронами между двумя чипами.

Электроны не достаточно быстро летают через AGP\PCI шину?

будующее

Убивать!

> 128 пора уже

для чего?

> зачем было ломать для 16-32-64???

КО: для адресации большей памяти

ок - а теперь представь каких объёмов была оператива в 90-х - это не так уж и давно было, и представь какие они будут в 20-30хх )))
и да - про «зачем» - только ради адресации? не верю!
ничего что на 64 софт соображает куда быстрей чем 32 и уж тем более 16?
и зачем тогда придумали костыли аля ss*e*?
думай дальше...

и да - вспомни про «640 кило хватит всем!» )))
и это было не так уж и давно - ЕМНИП в 86-ом

вру - 81

и да - вспомни про «640 кило хватит всем!» )))

А ты в курсе, сколько адресует 64-битный проц?

>и представь какие они будут

$ ls /proc/kcore -lh
-r-------- 1 root root 128T Авг 31 14:49 /proc/kcore