Зависит от задачи

В моем случае - управление железкой

Transmeta-way

//Для Ъ - VLIW с JIT-компилятором. Последний в теории может поддерживать любую систему команд.

Ради такого городить CISC неразумно ИМХО

Попробую развести срач.

Вот из-за того что сейчас большинство «программистов» - ленивые задницы, и делают все по течению, рождаются такие монстры как mono и прочие чудеса, для работы требующие железо уровня 2005-го года минимум. То же самое в сфере сабжевого управления железками - всем легче городить на знакомом x86, вместо того чтобы немного или много заморочиться с RISC. В итоге - терминалы оплаты на флеше, несущие в себе четвертопни с Гб ОЗУ.

В итоге - терминалы оплаты на флеше, несущие в себе четвертопни с Гб ОЗУ.

Да там P166 с 32 метрами за глаза хватит.

cisc труп, так что сам понимпешь.

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

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

ну так ты пользуйся кошерным си,

1К флешки

Эти бы слова, да в головы тех кто пишет интерфейсы на флеше и AIR

в общем, а чего ты еще ожидал от нормального эволюционного развития? Вот человек, например, тоже нагромождение костылей ))

это ж до фига (правда, если говорит не про avr, а про 8051)

но поддерживаемые ради совместимости много лет

Поэтому они и вытеснили другие, разве нет?

Туева хуча команд

Лучше, чем куча систем команд.

Да поймите вы, дешевле (и быстрее) купить и поставить мощные компы, чем написать код, который взлетит на P166 с 32 метрами памяти. У меня вот тоже чувство прекрасного страдает, но моё мнение не учитывается :)

проблема 2:

C уже умеет 3-х байтовые целые? 4-х байтовые не годятся, т.к. слишком нерационально регистры используются, а с 1-байтовыми ненамного проще выйдет, а может даже сложнее

Ага, а их обслуживание в будущем? Такими темпами скоро x86 в кофеварки ставить будут

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

Ну да ладно, тред вроде про avr, а я тут про свое кумекаю.

Проблемы то общие. Недостаток памяти.

дурацкая органицация памяти

а вот тут согласен. Да и система команд местами неудачна: невозможность использовать численные константы в r0-r15 сильно огорчает.

Лучше, чем куча систем команд.

Угу. Давайте создадим метасистему команд, 10000 инструкций на все случаи жизни. А потом будем рыдать, что энергопотребление неприлично высоко, и кристаллы по площади равны блюдцам.

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

Слава богу, Java-процессоры умерли, не родившись. А то скучали бы сейчас по «минималистичному» х86.

RISC, конечно! Я считаю, что x86 - раздутое костыльное говно. Пишу с ARM'а :)

В моем случае - управление железкой

forth никак?

Да поймите вы, дешевле (и быстрее) купить и поставить мощные компы, чем написать код, который взлетит на P166 с 32 метрами памяти.

А потом будет "быстрее купить мощные компы, чем написать код, который взлетит на i7 с 32 гигами памяти". С таким подходом обычная техника рано или поздно превратится в магию, которая вроде и работает, но как именно, и что у неё внутри - никто не помнит и не понимает.

Слава богу, Java-процессоры умерли, не родившись. А то скучали бы сейчас по «минималистичному» х86.

201 опкодов java против... эээ, а сколько там уже у x86?

А потом будем рыдать, что энергопотребление неприлично высоко, и кристаллы по площади равны блюдцам.

Скорее, наоборот. Вон, сравни плотность команд MIPS с x86.

давайте зайдём в тупик

Не вижу тупика. Компы всё ещё становятся быстрее.

лениво. Особенно писать обработку прерываний (и четко следить за временем исполнения) на форте.

С таким подходом обычная техника рано или поздно превратится в магию, которая вроде и работает, но как именно, и что у неё внутри - никто не помнит и не понимает.

Так уже. Магия. И давно.

«Any sufficiently advanced technology is indistinguishable from magic.» — Arthur C. Clarke

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

И? C и там рулит.

А что вам предпочтительнее - CISC или RISC? (комментарий)

201 опкодов java против... эээ, а сколько там уже у x86?

Сколько транзисторов надо, чтобы реализовать эти опкоды в железе? И сколько времени исполняется каждый опкод?

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

Скорее, наоборот. Вон, сравни плотность команд MIPS с x86.

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

Не вижу тупика. Компы всё ещё становятся быстрее.

Воздушного охлаждения перестало хватать. Потом перестало хватать тепловых трубок. Полагаю, через несколько лет вполне могут быть предложены СО на жидких металлах, ибо водяное не будет справляться. Процессоры с тепловым пакетом >100Вт - это, сторого говоря, пи#дец.

Этот подход сегодня диктуется рынком, вот и вся магия. Выставят тендер на разработку и победит не фанат ассемблера, а индус с быдлокодом.

Это пройдёт, просто сейчас период развития такой - количественный. А вот когда очередной мировой финансовый кризис окончательно развеет у людей все иллюзии по поводу их замечательного «рынка», и когда нехватка ресурсов отучит их от сверхпотребления, то наступит качественный этап развития. И тогда уж и индусам, и прочим cisc'ам придётся не сладко.

Сколько транзисторов надо, чтобы реализовать эти опкоды в железе? И сколько времени исполняется каждый опкод?

это не такой простой вопрос, как кажется. Можно конвеер замутить, а можно микрокод. OoO умножит число в несколько раз. Но стек это, конечно, очень медленно. Ждём dalvik-процессоров. :)

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

пишу с телефона на mips'е :)

Воздушного охлаждения перестало хватать. Потом перестало хватать

и он на 528 MHz ощутимо греется. Так что тут тоже вопрос спорный.

+1 x86 должен сдохнуть уже наконец.

Поэтому они и вытеснили другие, разве нет?

Вообще-то, не-x86 процессоров в разы больше, чем x86. Если не на порядок - два.

И кто кого вытеснил?

Вообще, если бы не долбаный мелкософт - нынче про x86 вспоминали бы как про Alpha ( тоже забавная хрень с этой альфой - DEC умудрились сделать как бы RISC-процессор с ужором больше чем CISC. PowerPC это тоже касается. Потому они и сдохли, а MIPS и ARM процветают. ).

это не такой простой вопрос, как кажется. Можно конвеер замутить, а можно микрокод. OoO умножит число в несколько раз. Но стек это, конечно, очень медленно.

Машинный стек если ты про него он же в памяти, конечно медленно.

Вы тут лучше посоветуйте где взять более-менее нормальный ноут на RISC, что бы можно было и киношечку посмотреть и java-быдлокодингом заняться

risc

http://armphetamine.sourceforge.net/images/armformat.png

Как будто бы RISC не может содержать команды умножения.

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

Умерли? Так вроде армы с суффиксом J выполняют байткод и доступны сегодня (якобы тот же raspberry pi). И, выходит, что у армов не программно.

очевидно поэтому он и называется risc, да? :)

А статических рекомпиляторов с ARM не встречал?

А мне по фиг: я без понятия, чем они отличаются. Знаю лишь, что в одном слишком до фига ненужного Г, а во втором и нужного-то не хватает.

из-за того что сейчас большинство «программистов» - ленивые задницы, и делают все по течению, рождаются такие монстры как mono

Шок! Сенсация! Раскрыта тайна рождения модератора!

и прочие чудеса

tazhate?

Либо новый лемоут на мипсе, либо это

Первое - дорого и недоступно, второе - очень дёшево, но для киношек - дуалбут в андроид, а для кодинга проц МБ слабоват. 1ггц a8.

пишу с телефона на mips'е :)

Я и говорю - узконишевое решение для сверхдешёвых сетевых/потребительских железок.

и он на 528 MHz ощутимо греется. Так что тут тоже вопрос спорный.

Pentium на 528 MHz требует принудительного охлаждения. Разница в потреблении энергии - на порядок.

И, выходит, что у армов не программно.

Да уж конечно! В лучшем случае, интерпретатор сидит в памяти, которая недоступна пользователю.

умножение на avr на асме, так так заскучал по x86

ты неправильный программер, программирование умножения на AVR ассемблере должно доставлять множественные оргазмы и вызывать отвращение к x86

RISC

Я и говорю - узконишевое решение для сверхдешёвых сетевых/потребительских железок.

А тем временем, пишешь ты либо с x86 (десктоп или ноут), либо с ARM (мобилка или таблетка). Оттуда-то легко рассуждать, да. А я вижу, каково это — на необычной архитектуре сидеть.

С mips'ами и на телефонах проблемы, не то что на десктопах. Причём это не абстрактные проблемы архитектуры, а тупо недостаток софта. Большую часть приложений, которые я ставлю на телефон, я пересобираю сам. Некоторые нужные, такие как Opera Mini, просто отсутствуют как явление. В итоге для потребителя телефоны на необычных (для mainstream) процессорах просто не существуют. Зачем нужен кирпич, на котором не запустить софт? Восхищаться превосходством архитектуры кирпича? :)

Поэтому x86 со своим наследием и рулит. На 8088 можно запускать софт для 8086, на 80286 можно пускать софт от 8086, и так далее. Это называют модным словом «экосистема». Для ARM специально придумали armeabi, чтобы эту экосистему создать, тогда как для x86 она исторически сложилась.

Разница в потреблении энергии - на порядок.

Q = U^2/R. Похоже, ты забыл про разницу в техпроцессе и использованном напряжении питания. Ты уверен, что если воспроизвести pentium того времени на 130 нм, то он будет требовать принудительного охлаждения?

И что это за понятие такое: «энергоёмкость инструкции»?

Ты кого больше любишь, маму или папу?

энергоёмкость инструкции

Если сжечь инструкцию, можно измерить, сколько выделится тепла :)