Опрос - новые инструкции.

Clerk

Защита от взлома, защита от вирусов или защита от рантаймовых ошибок с кривулями?

 

Clerk
"STARFORCE 2,3 ... N" или x32.NET/x32JAVA VM , неломаемая защита эта типа тама где кода нет, всмысле нету ножек нету мультиков =)
и сколько весить будет этот эмуль-VM ?

 

Ничего - наоборот повыбрасывать. До сегодняшнего дня считаю процессор Z80 наиболее оптимальным по набору инструкций. Собственно сейчас сложилась примерно следующая ситуация - все заверения производителей о том, что мощности современных CPU хватает лишь маркетинговая политика. Достаточно небольшого набора инструкций процессора, но чтобы они выполнялись максимально быстро. Поскольку последнее недостижимо, но начинают появляться MMX SSE 3DNow и прочие - это все лишь нежелание признавать одну проблему - несуществует технолгий на уровне физики существенно повышающих быстродействие процессора, вот и пытаются повысить его на уровне схемотехники и логики Кстати многоядерные процессоры - тоже яркий пример ...

 

PROFi
О_о зилог 80, у него практически идеальная система команд, чего тока стоят инструкции условного вызова процедур. Раньше я наизусть всю таблицу команд с расширениями помнил, гибче даже чем x86.

 

Clerk

Собственно все зависит от продуманости и принцыпов построения процессора. x86 содержит изначально заложенную излишнюю сложность, ибо детали электрической реализации перенесены в систему комманд. Кто пользуется 4 кольцами защиты или "развитой моделью сегментации" процессора - ответ очевиден - тупая сложность никому не нужна.

 

Быстрые эмуляторы - VMWare, VirtualPC, там это нужно.
http://ru.wikipedia.org/wiki/AMD64

 

Немного новых инструкций
http://softwarecommunity.intel.com/isn/downloads/intelavx/Intel-AVX-Programming-Reference-31943302.pdf

 

Система команд х86 создавалась "под человека". Отсюда сильная избыточность, неортогональность команд, смехотворное количество регистров.
PROFi

IMHO, так и должно быть - команды должны быть оптимальны для выполнения железом, не нужно нагружать процессор тем, что может сделать компилятор, причём значительно более эффективно.

 

И в чёмже эта избыточность ?
Там скорее одни недостатки.

 

Скорее не под человека, а под "смехотворные" объемы памяти первых x86. Человеку нафиг не нужны особые укороченные кодировки команд с "аккумулятором" и ряд других, не использующих байт ModR\M. И без кучки других команд типа loop,lods,jecxz,cbw и т.п. человеку можно спокойно обойтись (но "юные пионеры" их до сих пор юзают ради экономии байтиков . Ну и причина "смехотворного" числа регистров происходит из той же экономии, т.к. в кодировку байтов ModR\M и SIB только 8 регистров и влезают (и то со скрипом), а добавлять лишний байт почти на каждую инструкцию, ес-но "жалко"

 

Ну а по мне Z80 имеет отвратительную систему команд -- потому что создавали, сохраняя совместимость с 8080...

 

green

Число комманд и их непосредственный вид - прямое отражение архитектуры чипа. Если архитектура г..но то исистема комманд такая же. PS: изначально система комманд должна разрабатываться а потом уже чип.

 

z80 никаких тебе защит от записи кода, ностальгия...

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

 

Учитывая, что реальной возможности оказать влияние на развитие х86 у нас нет хочу спросить (безотносительно к существующим и существовавшим архитектурам) - какой формат команды и систему команд (целочисленую) кто считает наиболее удобной (не минимальной)? Желательно чтобы накладные расходы по железной реализации были поскромнее. Скажем, длина команды фиксирована и == 32 бита.

 

Улучшенный вариант системы команд VAX-11 (увеличение числа регистров, избавление от некоторых странностей, возвращение косвенной автодекрементной адресации, ещё кой-какие улучшения, ну и плюс введение команд типа SSE). Длина команды переменная, естественно А если фиксированная -- это уже RISC, как ни крути, причём достаточно извращённый.

 

SII
У меня в 32 бита влезло - трехадресная схема (32 или 16 регистров (ip флаги и перенос в общих регистрах)). Возможное условное выполнение любой команды. Возможная установка условий любой командой. Возможность работы с регистром или по ссылке в регистре. Возможный постинкремент каждого из трех регистров команды (при регистре на 1, а при ссылке на длину слова). 32 команды. Возможность работать с данными разной длины (от байта до .. скажем, килобайта). Чето еще.. (сдох ехель подглянуть не могу) Положение и значение полей в команде постоянно.

Что скажете?

 

_basmp_

это по CF, ZF?

 

Не о том мечтаете. Было бы полезнее сделать регистры общего назначения 128-битными и чтобы ими можно было оперировать не только как целыми, но и как числами с плавающей точкой. Ну и чтобы их было хотя бы 16. А то в данный момент как только начинаются расчёты с высокой точностью, так сразу приходит Большой Волосатый Джоппа.

 

_basmp_
Да много что ещё. На самом деле сплошные трёхадресные команды не годятся: многие по определению одно- или двухадресные, в то же время полно команд, которым большее число операндов нужно бы...

 

В форматах инструкций никакой логики нет, они сложны даже для анализа.