OSDev

А от чего по-твоему надо отказаться в AMD64 и чего добавить? Чем другие процессоры лучше?

Если коротко -- отказаться от всего :) Система команд изначально крайне неудачная (у интела вообще ни одной хорошей в этом плане архитектуры, пожалуй, и не было, хотя утверждать категорически не могу, поскльку не знаком со всеми), ну а все последующие дополнения и изменения, хотя частично её улучшили (например, сделали регистры общего назначения более "общими", чем было изначально), но носили характер костылей. 64-разрядное расширение -- такой же костыль, причём весьма и весьма кривой (достаточно разобраться в кодировании команд). Устройство управления памятью тоже переусложнено (опять-таки, из-за кривизны ранних реализаций, последующего расширения и т.д. и т.п.). Неудачна система прерываний. В общем, в этой архитектуре вообще нет абсолютно ничего положительного (ну а то, что существуют ещё более кривые процессоры, сути дела не меняет).

Вообще-то за кодировку AMD64 отвечает AMD :) Да меня она и не особо волнует, поскольку я не кодирую, и ассемблеров не пишу.

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

Но кодировка эта базируется на кодировке Интел. У АМД не хватило ума полностью отказаться от каких-либо намёков на совместимость для 64-разрядного кода.

Ну а волнует или не волнует... Это вроде бы никого практически не волнует, но напрямую отражается на сложности процессора, а значит, на его цене, потребляемой мощности, площади кристалла... -- а это уже косвенно или даже прямо затрагивает конечных потребителей. Уже сегодня можно констатировать, что интеловские процессоры царствуют только там, где им пока вообще нет конкурентов: ну не выпускаются процессоры других архитектур для ПК -- главным образом, по причине отсутствия вменяемого ПО под эти самые другие архитектуры. Ну а посмотришь ниже, на всякие там мобильники и прочие планшеты -- и окажется, что там изделий на базе процессоров интеловской архитектуры (не важно, чьего производства -- самой Интел, АМД, ВИА, ещё кого угодно) практически нет. И дело не в том, что, например, Атомы плохи сами по себе, просто они вчистую проигрывают АРМам абсолютно по всем показателям, кроме, разве что, производительности (и то под вопросом), но последняя характеристика для мобильных применений значит куда меньше, чем энергоэффективность, ну и цена далеко не последнюю роль играет... А если посмотреть выше, то там тоже ИА-32 несладко приходится. Есть ИБМовские мэйнфреймы, архитектура которых эволюционирует с 1960-х годов и жива до сих пор (поскольку была тщательно продумана в своё время, да и расширялась не от балды); есть SPARCи (что с ними будет -- вопрос скорей финансово-маркетинговый, чем технический: Sun в трубу вылетела из-за неграмотного руководства компанией, а не из-за плохой продукции; та же участь в своё время многих постигла); есть суперкомпьютеры на графических процессорах от nVidia...

В общем, если АРМ разродится и выпустит достаточно вменяемую 64-разрядную архитектуру в дополнение к своей 32-разрядной (которая неплоха, хотя и не без уродств), тогда ИА-32 будет постепенно вытесняться ею и из ноутбуков и традиционных ПК. Если у АРМ не получится, то кто-нибудь ещё появится через некоторое время -- свято место пусто не бывает. Понятное дело, что процесс этот небыстрый (в силу огромного количества ПО под ИА-32), но, по сути, неизбежный -- как раз в силу врождённых пороков ИА-32, которые невозможно исправить.

Пы.Сы. Я тут никого не агитирую; кому что нравится, тот тем и занимается.

По поводу SMM - спасибо, это новая для меня информация.
По-поводу страничной памяти суперскалярности, кэширования и т.д. Если я правильно понимаю, то все эти навороты не делают i686 принципиально непригодным для ЖРВ. Однако, конечно, усложнение архитектуры ЦПУ приводит к усложнению расчета таймингов. Но если я правильно понимаю, тот же Intel используя свою внутреннюю инфраструктуру сможет рассчитать все тайминги без особых проблем.
По-поводу x86 vs ARM.
a) Поскольку архитектуре х86 уже несколько десятков лет, она накопила известное количество говна благодаря закону сохранения обратной совместимости. Вечно так продолжаться не сможет, и рано или поздно они или сами у себя проведут ревизию архитектуры, либо их подвинет другая компания с более молодой архитектурой. То же касается в целом и архитектуры IBM PC. Та же судьба в конечном итоге ждет и ARM и любую другую долгоиграющую архитектуру.
b) И ARM и x86 заняли свои ниши рынка. Плюсы одной - это минусы другой. Глупо запиливать х86 в мобильник ибо батарея сядет за 2 часа, так же как и глупо пихать ARM в рабочую станцию ибо производительность будет более чем бедная.

В теории Интел, конечно, может, на практике -- фиг знает (возможно, просто слишком большое число вариантов надо рассматривать, чтобы точно определить наихудшие времена). Однако, если используется виртуальная память (т.е. не просто страничный механизм включен, а используется выгрузка на диск), то ЖРВ возможно лишь для кода и данных, которые всегда находятся в физической памяти, поскольку время подгрузки с диска, даже если оно само по себе невелико, абсолютно непредсказуемо (хотя бы из-за того, что диск может подсбаивать и в итоге считать нужный блок с ннадцатой попытки).



Ну, АРМ не шибко моложе, особенно если сравнивать с ИА-32, а не с 8086, и тоже не без говна. Насчёт судьбы тоже спорить трудно. Есть, правда, один важный момент: качество первоначальной архитектуры и её дальнейшего расширения. У Интел архитектура была изначально ужасной, ну а в дальнейшем становилась всё хуже и хуже (хотя с точки зрения программиста отчасти было и наоборот; например, были смягчены ограничения на использование регистров -- но ценой резкого усложнения кодирования команд; тут правильней было бы полностью отказаться от совместимости с 16-разрядным кодом в плане кодирования и делать полностью новую кодировку -- так, например, поступила DEC при разработке 32-разрядной VAX-11, которая могла выполнять и 16-разрядный код PDP-11). У АРМ архитектура была существенно лучше, а её недостатки связаны в первую очередь с тем, что изначально это были РИСК-процессоры. Сама концепция РИСК с треском провалилась (как показала эволюция процессоров, в итоге ЦИСК обгоняет любой РИСК на любых задачах, кроме крайне специализированных "числодробительных", ну а на последних классический РИСК будет вдребезги разбит графическим процессором), но тяжкие последствия ощущаются и будут ощущаться дальше, поскольку просто так взять и ликвидировать их невозможно, требуется кардинально переделывать систему команд.



Угу, но у АРМа производительность постоянно растёт, а у ИА-32 фактически дошла до предела (наращивание числа ядер не в счёт; в конце концов, на той же площади кристалла АРМовских ядер поместится прилично больше). Так что на ПК позиции ИА-32 пока незыблемы не из-за производительности, а из-за огромного количества готового ПО, чего на АРМе нет.

Конечно, если под использованием страничной памяти подразумевать подкачку с МЖД то ни о какой предсказуемости не может идти и речи. Хотя я думаю что подкачка с SSD может быть предсказуема, но это уже отдельный большой вопрос.

Так фишка та в том и заключается, что история обратной совместимости начинается с 8086. :(

Я боюсь, что когда ARM дорастет по производительности до Core I7, он уже будет очень сильно похож на последний и по производительности и по сложности и по тепловыделению.

Фактор софта конечно серьезный, но существует ряд областей где этот фактор играет малую роль: спец-сервера, научные исследования, и т.д. Тот же *NIX мир спокойно скомпилируется под ARM.Но никто не будет этим заниматься, потому что ARM не приспособлен под высокопроизводительные вычисления. Его козырь энергопотребление.И если он будет усердно гнаться за производительностью, то потеряет этот свой козырь и Intel легко вытолкнет его с рынка. Поэтому я считаю, что если не произойдет какой-нибудь революции у одной из сторон, они так и будут еще долгое время сидеть в своих сегментах рынка и не высовываться.

Если б... Придурки из Интела решили обеспечить полную "логическую" совместимость с 8080, т.е. каждой команде 8080 прямо соответствовала одна из команд 8086 (хотя на уровне машинного кода, да и мнемоник они разные были). А 8080 тянет совместимость, хоть и не полную, с 8008... В общем, маразм полный, тем более, что тогда не было проблемы с большим количеством уже существующего ПО.



Если говорить чисто про 32 разряда (а 64-разрядных АРМов пока в природе не существует), то не будет, и не в силу разрядности, а в силу простоты архитектуры (ведь ИА-32 намного сложней и без всяких 64-разрядных расширений, они лишь ещё больше добавляют сложностей). Соответственно, будет по-любому устроено проще, греться меньше и т.д. А вот что за 64 бита АРМ родит (и когда), пока неясно.



Замечу, что и системы ЖРВ -- узкоспециализированные (хотя бы потому, что там недостаточно сделать ОС, там нужен весь комплекс -- и программный, и аппаратный).

А вот насчёт "потери козыря" Вы ошибаетесь. При прочих равных будет выигрывать более простой процессор. Для обеспечения того же количества и скорости выполнения микроопераций в тактах два процессора разной архитектуры должны иметь одинаковое количество исполнительных устройств и одинаковую частоту, так что здесь суперскоростной АРМ и ИА-32 буду одинаковы. Кэши тем более одинаковы. А вот блок выборки и декодирования команд отличается очень существенно, и не в пользу ИА-32 -- из-за сложной и запутанной системы команд последнего. Другое дело, что здесь не будет разницы в потреблении и сложности в разы, но в любом случае АРМ будет в выигрыше. Но если АРМ сможет покрывать практически весь рынок (от самых мелких применений, где сейчас обычно используются 8-разрядные микроконтроллеры, и до высокоскоростных, реализуемых на традиционных процессорах -- графпроцессоры всё ж не в счёт, это отдельный случай), то ИА-32 на это не способен в принципе из-за своей сложности. Таким образом, в теории он будет всегда в проигрыше. Другое дело, что на практике пока конкурентов в "верхней части списка" ему нет.

Нет, ну в целом я разделяю вашу точку зрения. Если уберARM будет представлять собой Core i7 c выпиленными обратносовместимыми костылями, то будет проще и просто лучше. Но мне кажется, что эти костыли представляют из себя от силы 5% от сложности. Остальные же 95% сложности запилены сознательно для увеличения производительности.

Не совсем так. Большую сложность в процессорах ИА-32 создаёт изначально уродская архитектура, а не забота о совместимости как таковой. У ИБМовских мэйнфреймов даже сейчас, после почти полувековой эволюции, эта самая архитектура остаётся стройной и логичной, отягощённой минимальным количеством костылей, хотя совместимость прикладного кода сохраняется (от совместимости системного отказались в 1990-х). Ну а у ИА-32 с этим всё очень плохо изначально, причём благодаря АМД был упущен единственный шанс решить проблему кардинальным образом: оставив сложные и запутанные блоки для исполнения унаследованного 16- и 32-разрядного кода, новый 64-разрядный сделать уже по-человечески, благодаря чему в перспективе можно было бы полностью отказаться от поддержки совместимости и резко упростить процессор. В самом деле, многим ли сейчас нужен 16-разрядный код? Да и 32-разрядный постепенно сдаёт позиции. Ну а АМДшников хватило лишь на отказ от сегментации и ещё пару мелких улучшений, но никак не кардинальное реформирование системы команд...

Главная сложность любого высокопроизводительного процессора -- это его блок управления, ну а его конструкция напрямую зависит от сложности и стройности системы команд. В частности, именно этот узел декодирует команды и порождает микрооперации, которые потом выполняются остальными блоками процессора. Все же остальные узлы устроены многократно проще и практически не зависят от системы команд и прочих вещей, видимых со стороны пользователя (программиста). Вот и получается, что ИА-32 сложней как раз в том месте, которое и само по себе самым сложным является: его систему команд куда сложней дешифровывать, чем армовскую (даже просто определить границы команды -- сколько байтов она занимает -- на ИА-32 намного сложней). Поэтому те самые 95% сложности для ускорения работы на ИА-32 многократно сложнее, чем у АРМа.