>Кому от этого холодно или жарко, это влияет на производительность чипа? Совершенно
>никак не влияет.Это влияет на его потребление.Транзисторы создают чтобы переключаться.В таких устройствах совместимость с x86 никому особо не впилась а вот лишний жрач обычно совсем не пофиг.Потому что чемодан батареек в комплекте - не рулит.В ноутах для компенсации этого используется именно такой подход.Посмотрите на ноутбучную батарею.А потом на КПКшну.Возьмите калькулятор.Посчитайте запас энергии в ваттах в каждой из батарей.Проникнитесь разницей.Кстати, ваттаж батарейки дается вполне очевидным методом - батарейка становится в соответствующее число раз объемистее и увесистее.
>даже тока не потребляют.
x86 сам по себе CISC а потому для работы при прочих равных ему придется задействовать намного больше вентилей чем RISCовому ARM с крохотным ядром.Кстати даже если транзистор не переключается, есть еще токи утечки.Так что пи***ж.Будут жрать, куда ж они денутся?
>(например запустить ДОС(!),
На *таком* устройстве это никому не надо.
>очень много систем промышленной автоматики
Данные железяки не созданы для целей промышленной автоматики.Для оных есть PC-104 всякие и прочая хрень, где жрач всем пофиг, зато местами даже шина ISA бывает, по соображениям совместимости.Но это совсем иной сегмент рынка.
>время работают под управлением этой ОС, неоднократно сталкивался) - вентили эти
>будут очень кстати.
На этом девайсе - не будут.Там где будут - x86 уродца и используют.PC104 всякие там и подобные костылики.
>Это вообще бред какой-то. Посмотрите на досуге в отладчике код современных видеокодеков,
>например, какие они инстркуции используют.
Mplayer на n800 как-то себя достаточно неплохо чувствует с тамошними инструкциями VFP+ARM6 довольно ничего так(SIMD команды там есть, думаете кроме интеля все дебилы?).А на подходе OMAP3 с его Cortex A8 ядром и набором команд Thumb2.Вот это весьма интересные штуки, потому как плотность инструкций повышена и памяти сильно полегчает.
А если x86 спустить на 400 МГц то он пожалуй еще и сольет ARMу и по скорости и по жрачу.Особенно если вспомнить что у OMAP есть еще и DSP который для всяких там MP3 кодеков весьма удобен как раз.DSP может справиться с MP3 за мизерное время на малой частоте.А x86 придется для этого молотить в разы больше на куда большей частоте.Сажая ессно батарейку пропорционально сильнее.
>Абсолютно пустая, "ниочемная" неаргументированная фраза. Такую я могу бросить по отношению к
>любому процессору.
... но применительно к х86 это еще и правда.Скажем, декодировать x86 команды в более простые через микрокод и\или декодеры - это не изврат?А зачем вообще все это?Почему нельзя сразу подать набор RISC команд которые не надо декодировать?Зачем лишние элементы процессора?Да, в 80-х годах может какой-то смысл был.А в 2008 в х86 все это только ради совместимости... Технически же и компилятору и программеру удобнее работать с RISC абстракцией с кучей равноправных регистров.И заниматься онанизмом с push-pop стека во многих случаях не надо - скорость от этого только выиграет т.к. нет бесполезных операций.А у какого-нить ARM если что-то надо в стек запихать - в 1 команде можно не только указать что вон то в стек, но еще и можно указать что именно как маску, сэкономив на обращениях к памяти и числе команд (одной командой можно засунуть в стек скажем, R3 и R5-R8 которые мы намереваемся юзать - удачи так на x86, ага).При том это можно как и вручную так и на уровне компилятора в общем то.Еще в x86 нет относительной адресации.Поэтому при загрузке программ и библиотек на х86 как правило дооооооолго педалятся уродские воркэраунды типа таблиц релокаций, позволяющие все-таки запихнуть программу\бибилу в нужные адреса путем туевой хучи пересчетов разных констант и хардкорного патчинга половины программы.Это конечно же совсем не через зад, да!И скорость старта программ от этого не страдает, конечно же!В х64 кстати хоть от этого уродства немного избавились - появилось и больше регистров и относительная адресация.Контроллера прерываний у x86 нет.То что в PC - древнее угробище.И с ним по сей день надо быть совместим.Потом туда приделали сбоку APIC, ... У того же ARM все сильно проще.И сразу на борту.У ARM вообще как правило все на 1 кристалле - мизерном и экономичном.И он не такой тормоз в обработке прерываний.Особенно когда юзаются (костылики относительно ранней инкарнации ARM :D) типа векторизированых контроллеров прерываний.Современный x86 как и раньше давится и дохнет на кучах прерываний.
>на регистры, другой на стэк, третьи на операции с памятью, Вот
>х86 как раз такой.
х86 - это процессор с архитектурой которая была актуальна 20 лет назад.А сейчас это живет по принципу "уж что выросло, то и выросло".Вся эта пачка костылей неизбежно жрет энергию, усложняет чип и т.п..
>Для этого у него есть хитрые алгоритмы кэширования,
... на которые + кэш топовые х86 тратят миллиарды транзисторов.С соответствующими результатами как по росту скорости так и по росту потребления.
>предсказания переходов и еще целая куча умных технологий.
(костылей, жрущих тучу электричества - так и запишем :D)
>RISC-архитектуры могут долго с пеной у рта критиковать х86, но реального
>положения вещей это не изменит - эта архитектура на данный момент
>безраздельно правит балом, и не безосновательно.
x86 правит балом там где есть дофига паталова.А на 1 х86 в десктопе найдется пяток ARM вокруг в мобильных устройствах и вагон-другой прочих мелких RISC в качестве управляющих процессоров (микроконтроллеров).Интель пыжится пролезть на эти рынки, атом - это уже 3-я попытка.Столь же безуспешная как и остальные две.Атом хорош в "нетбуках".У которых батарейка все-таки ноутбучная а совместимость с PC там может иногда сойти за плюс (например, некоторые там могут захотеть Win XP).А линуксу строго говоря пофигу на чем работать - он весьма портабельный и без проблем работает на ARM в n8x0, на MIPS в роутерах и прочая.Даже на экзотах типа Tensilica и AVR32 работает.И никто особо и разницы не заметит.В конечном итоге майнтайнерам довольно однохренственно под какой именно проц сорцы скомпилять.Компиляет то компилер а ему пофиг - он железный.А там лишь бы описание процессора было в компилере.В конечном итоге пашет тот же GCC, ну сгенерит он не i386 а ARM код, кого это колышет то?А юзеру 1 фиг готовые пакеты ставить.
