Ну и что об этом думает уважаемый all?

http://www.atmel.com/dyn/corporate/view_de...short_2_14.html

http://www.atmel.com/products/AVR32/

400 мгц однако. Интересно теперь реальное потребление, корпуса, возможности отладки и цены. Вот вам и АРМ9 блин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

Для профессионального писательства на АSM и с 32бит регистрами и полным (в отличие от охремонно регистровых архитектур ничего кроме пересылок регистр-память не имеющих) набором команд для работы с памятью ограничение вполне мягкое.
За плечами проект тянущийся со 286 процессора. Порядка 200K кода, исходники до размера всех трех томов Войны и Мира не дотянули правда, операционка, виртуальные машины, Ethernet, всякой хрени включая шустрые поиски в базах....
На момент перехода на 486 досаду от нехватки регистров испытывал максимум пару раз.
Досада от сопровождения всего этого дерьма на ASM ни в какое сравнение с проблемами нехватки регистров не идет.

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

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

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

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

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

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

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

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

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

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