[SapegoAL 0]

Я не обижаюсь. :) Я упрощаю. Я просто прошу признать, что совместимость вначале приводит к рывку, а потом, ч/з определённое, время является тормозом. Ответьте только на этот вопрос. Да или нет?

 

Не могу сказать, что прекрасно знаю что именно эмулируется в новых матерях , а что нет, но не думаю что кто-нибудь знает реально намного больше. По простой причине. Сейчас сложно влазить в переферию. Даже те кто делает платы под PC врядли владеет полной информацией где что и как там работает. Ну уж не до такой степени я отстал как Вы считаете. Я тем не менее экспериментировал (хотя и чисто для любознательности) как работает та или иная переферия. В частности soft и hard модемы, звук, клава, порты и т.п. Хотя признаю что знаю здесь мало. :) Сейчас совсем времени на самообразование недостаточно. :) Но я стараюсь.

 

Ну ответьте тогда Вы. Почему на Ваш взгляд у этого камня нет никаких шансов? Чем он так плох? И неужели Вы считаете, что система комманд вообще ни чего не решает? А что тогда? Почему именно Вы не хотите его применять я понял конечно сразу. :) Признаю. Ваша позиция в этом вопросе прояснилась для меня ещё на обсуждении PICов. :)

 

Я не буду больше плодить флуд и флейм. :) Простите за этот. И остановимся на Вашем ответе.

 

:cheers:

[zltigo 2]

Хотя признаю что знаю здесь мало. :) Сейчас совсем времени на самообразование недостаточно. :) Но я стараюсь.

Успехов! Я просто использую индустриалки в своих системах в некоторых случаях со своей старинной операционкой писанной на, черт побери, ASM - приходится копаться :(

Ну ответьте тогда Вы. Почему на Ваш взгляд у этого камня нет никаких шансов?

Уже дважды писал - монопольное ядро в нынешних времена массовым не будет. Под массовостью имеется ввиду не количество (запихнут в Nokia мобильники уже будет немало) чипов а количество разработчиков и производителей его использующих.

Чем он так плох?

Да не плох он, он ОБЫЧЕН.

И неужели Вы считаете, что система комманд вообще ни чего не решает?

Решает, но далеко не все и даже не является принципиальной. Даже Вы в своей отповеди x86 все не о системе команд говорили а сугубо о системообразующих вещах. В том-же Cell разработчики отнюдь не системой команд размахивают а наихитрейшими хитростями по утаптыванию ядер в "целое", да поднятию скоростей обмена с памятью. А про программирование думают опять исключительно в разрезе, как задачу-то расспараллелить на охременное количество ядер. Поднимут системы программирования многодерных процессоров до повседневного использования - запихнут мамнадцать доступных, например, ARMообразных (и не будут особо даже голову ломать над системой команд) ядер в чип и все.

[SpiritDance 0]

Да вобщем никто не говорил о лидерстве. Тему я вообще создал из интереса к новому ядру, это просто интересно как программисту, а не как аналитику по развитию рынка. Однако сам думаю - кристалл некоторый кусок рынка захватит, и вообще... поживем-увидим.

[CD_Eater 0]

Но система команд, структура регистров были бы в корне отличными!

Ну и какими?

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

Где сейчас (уже спустя еще 20 лет), хоть в проектах и высоконаучных статьях это в корне отличающееся чудо?

В 64-битных пнях. Там всё по-другому.

[zltigo 2]

В 64-битных пнях. Там всё по-другому.

Они стали не совместимыми с 86? Все "по другому" с точки зрения набора команд, стало уже в 386.

С точки зрения архитектуры все "по другому" на каждом новом чипе делают. Так-что поминать 86..286 в качестве неправильных процессоров можно, но распространять их проблемы на все совместимые чипы и поминать поддержку совместимости команд в качестве чего-то жутко обременительного право не стоит.

[CD_Eater 0]

С точки зрения архитектуры все "по другому" на каждом новом чипе делают

Оптимальный скомпилированный код для 386 оставался почти оптимальным для всех x86 вплоть до Pentium-4. А вот на новых 64-битных процессорах для получения адекватной производительности придётся программу перекомпилировать. То есть, на уровне бинарников совместимость присутсвует, но весьма сомнительна ("для галочки").

 

Так-что поминать 86..286 в качестве неправильных процессоров можно, но распространять их проблемы на все совместимые чипы и поминать поддержку совместимости команд в качестве чего-то жутко обременительного право не стоит.

Именно команд (и регистров). Независимо от железа, реализующего x86-совместимый МП, ограничение в количестве регистров жутко тормозило прогресс, и это нельзя преодолеть, не отказавшись от совместимости. Да и сетка кодов инструкций со временем перестала быть похожей на оптимальную, увеличивая длины инструкций. Мне кажется, отрицательное влияние совместимости очевидно.

 

Оправдание этому - обилие софта и его дороговизна. Почему большинство юзеров покупали PC-совместимые компы? Потому что под них уже было написано много полезного и нужного софта, это важнейшая причина их популярности. Несовместимость могла убить серию x86. А вот в случае с МК несовместимость не фатальна, имеет смысл ставить на первый план вопросы себестоимости и быстродействия, а отдавать предпочтение совместимости лишь при прочих равных условиях.

[zltigo 2]

То есть, на уровне бинарников совместимость присутсвует, но весьма сомнительна ("для галочки").

Мы это о чем? Зачем "плавно" полезли в качество работы старого набора команд?

 

 

 

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

Так уж и жутко - высокоруровневые языки так или иначе на стек завязаны, то, на чам реально тормозят процесс обработка потоков данных, графика и иже с ней, что ни в какие регистры по любому не влезет. Это в Вас котроллерщик пишущий на ASM простые программы обработки маленьких обьемов информации говорит :(.

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

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

Мне кажется, отрицательное влияние совместимости очевидно.

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

[CD_Eater 0]

Это в Вас котроллерщик пишущий на ASM простые программы обработки маленьких обьемов информации говорит

Не угадали. :) Я 15 лет занимаюсь программированием, в том числе есть большие проекты на x86 ассемблере. И очень хорошо знаю, чего стоит разработчикам ограничение в 8 регистров. Некоторые предпочитают не видеть эту проблему, отказавшись от ассемблера и ваяя в ЯВУ. Но проблема-то останется ;) Кстати, большинство оптимизирующих компилятров пользуется стеком лишь когда не хватает регистров. Вероятно, Вы никогда не заглядывали в ассемблерный листинг PC-программ.

[zltigo 2]

Я 15 лет занимаюсь программированием, в том числе есть большие проекты на x86 ассемблере.

Аналогично, только лет побольше и проекты бывали очень большие.

И очень хорошо знаю, чего стоит разработчикам ограничение в 8 регистров.

Для профессионального писательства на АSM и с 32бит регистрами и полным (в отличие от охремонно регистровых архитектур ничего кроме пересылок регистр-память не имеющих) набором команд для работы с памятью ограничение вполне мягкое.

За плечами проект тянущийся со 286 процессора. Порядка 200K кода, исходники до размера всех трех томов Войны и Мира не дотянули :) правда, операционка, виртуальные машины, Ethernet, всякой хрени включая шустрые поиски в базах....

На момент перехода на 486 досаду от нехватки регистров испытывал максимум пару раз.

Досада от сопровождения всего этого дерьма на ASM ни в какое сравнение с проблемами нехватки регистров не идет.

Вероятно, Вы никогда не заглядывали в ассемблерный листинг PC-программ.

Не заглядывал :) - я с ними работаю.

[CD_Eater 0]

Ну, попробуйте для разнообразия закодировать какой-нибудь криптографический алгоритм (или просто операции с большими числами) - сразу почувствуете, сколько регистров надо для счастья. Кстати, за это люблю AVR8, там регистров - хоть ж...й ешь.

А для "общего" программирования (где нет сложных критичных ко времени алгоритмов) и одного аккумулятора хватит. :)

[zltigo 2]

Ну, попробуйте для разнообразия закодировать какой-нибудь криптографический алгоритм

(или просто операции с большими числами) - сразу почувствуете, сколько регистров надо для счастья.

Легко. Опыт есть.

Уже писал - система команд x86 позволяет нормально работать с памятью, в отличие от обычного явления для простых многорегистровых архитектур (в том числе и ARM) в которых нихрена не сделаешь не распихав предварительно "большие числа" по многочисленным регистрам с последующей обратной пересылкой в память.

Кстати, за это люблю AVR8, там регистров - хоть ж...й ешь.

Кушйте на здоровье :).

[CD_Eater 0]

Легко. Опыт есть.

Уже писал - система команд x86 позволяет нормально работать с памятью

Вот и приходится работать с памятью, временно загоняя туда регистры, чтобы потом через несколько инструкций их оттуда читать. Увеличение количества регистров в два раза значительно бы ускорило выполнение кода. Железо в идеале может сделать обращение к памяти таким же быстрым, как к регистру, но не может уменьшить количество бесполезных пересылок туда-сюда. Из 8 регистров один указатель стека, другой указатель фрейма стека, дальше нужны пара указателей на буферы в памяти, один счётчик цикла, и остаётся для собственно самих вычислений почти ничего. Так что "легко" не получается. Меня каждый раз душит жаба, когда приходится тратить драгоценные такты на временное сохранение в память из-за нехватки регистров. Можно, конечно, на всё положить и писать не задумываясь о тактах, как Вы наверное и делаете, но это "лишь бы написать код", а не "написать эффективный код". Архитектура должна давать возможность (по крайней мере, не препятствывать) написанию эффективного кода, а тут получается прокрустово ложе. Ф топку! Собственно, уже там (с переходом на 64-битники).

[zltigo 2]

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

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

Типа:

shl dword ptr [eax],3                
xor dword ptr [eax+ebx*4+8],1234h

Когда с ARMом начинал работать как раз скомпилил кусочек AES алгоритма IAR-ом под ARM и Watcom-ом под 486 для общего ознакомления. По количеству команд 486 был где-то 190 команд и 500 байт размер. У

ARM более 250 команд и соответственно размер боле 1000. C оптимизацией я естественно разобрался до эксперимента. Работа была с матрицей, вот уж где пересылок туда-сюда у ARM насмотрелся :(. Регистов IAR из всего богатства использовал семь, Watcom - пять.

[klen 1]

под 486 для общего ознакомления. По количеству команд 486 был где-то 190 команд и 500 байт размер. У ARM более 250 команд и соответственно размер боле 1000.

 

Это конечно ДА! но не надо забывать что как правило на CISC машинках эти 190 команд будут значительно медленне для заданной частоты конвеера чем 250 RISC команд, за что и платится в общем случае большим объемом кода (собсна платится за простоту и скорость RISC ядра)

 

А на счет удобства... это вопрос не конкретный. Комуто вообще WLIW лучше, мне так многорегистровые архитектуры нравятся больше. А кто асма не видел ему и вообще плевать.

По мне так все зависит от конкретной задачи.

[CD_Eater 0]

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

А вы посмотрите, сколько тактов займёт прямые операции с памятью без загрузки в регистр. Видимо, вы вместо быстродействия кода заботитесь об удобстве программирования. Это разные вещи.