N>Смотрим на какой-нибудь ARM и видим возможность and/or со значением типа "сдвинуть константу 1 на указанное число бит".
Например, такую команду ?

N>А вообще очень прошу объяснить, почему это вдруг такие команды стали "мрачными отголосками CISC".
N>Накойхер (tm) требовать переводить в цепочку "загрузить 1 — сдвинуть — выполнить операцию" то, что элементарно выполняется в пределах одной команды чуть более продвинутым железом?
Так никто не делает.

N>Или Вы по-прежнему в рамках ложной парадигмы "RISC это когда очень мало разных команд"?
E>>История уже поставила все точки на i.
N>Я боюсь, что она поставила немного не те точки, чем вы
Я не являюсь историей.

E>>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.
N>А покажите. Какой-нибудь код общего назначения типа qsort.
Покажу, но позже.

M>То-то на ARM'е всякие Thumb'ы прикручивать стали
Thumb — это тяжелое 16 битовой наследие. Сейчас его никто не использует.

Здравствуйте, eskimo82, Вы писали:

E>>>>Вот только в 80-е годы процессоры были 8 и 16 битными. 8 битный RISC сделать весьма проблематично, слишком мало команд в 8 бит влезет, а 16 бит на команду расточительно.
E>>>1) Z80 и i8080 — это 16 битовые процессоры.
M>>Да шо ви говорите?
E>См выше. Я там уже все написал.
Ну, вообще-то мой сарказм относился в данном случае к выделенному утверждению

M>>2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
M>>Сами опкоды? наверно. Так и у i8080 все опкоды в байт помещались.
E>Опкоды и мелкие данные (до 4 бит).

Википедия с тобой не согласна

Количество инструкций[править | править исходный текст]
Нередко слова «сокращённый набор команд» понимаются как минимизация количества инструкций в системе команд. В действительности, инструкций у многих RISC-процессоров больше, чем у CISC-процессоров.[6][7] Некоторые RISC-процессоры вроде транспьютеров фирмы INMOS (англ.) имеют наборы команд не меньше, чем, например, у CISC-процессоров IBM System/370; и наоборот — CISC-процессор DEC PDP-8 имеет только 8 основных и несколько расширенных инструкций.
На самом деле, термин «сокращённый» в названии описывает тот факт, что сокращён объём (и время) работы, выполняемый каждой отдельной инструкцией — как максимум один цикл доступа к памяти, — тогда как сложные инструкции CISC-процессоров могут требовать сотен циклов доступа к памяти для своего выполнения.[8]
Некоторые архитектуры, специально разработанные для минимизации количества инструкций, сильно отличаются от классических RISC-архитектур и получили другие названия: Minimal instruction set computer (MISC), Zero instruction set computer (ZISC), Ultimate RISC (также называемый OISC), Transport triggered architecture (TTA) и т. п.

M>Мало ли для чего ее придумали — на спектруме она во всю использовалась — команда работы с регистром — 4 такта, та же команда с памятью — семь тактов — почти в два раза замедление — думаешь, никто не использовал лишние регистры? А ПЗУ спектрумовское никто и не вызывал почти, там мало полезного было
Обработка IRQ подразумевала переключение страницы регистров. Ваш Кэп.


M>Абсолютные. По твоей же ссылке:
См. выше и научись читать уже же наконец.

E>>>Использовалось это все активно, и это позволяло не только экономить память, но и писать программы, которые сразу же штатно работают загруженными по любому адресу памяти, без всяких таблиц трансляции адресов.
E>>Ну а можно было и с битовой табличкой патчить адреса — это в принципе до сих пор так и осталось, хотя использовалось в последний раз в DOS.
M>Таблицы релокации есть и в PE, и используются, если что.
M>Но только эту таблицу релокации надо тащить вместе с кодом, загружать, патчить — кому это надо? Плюс размер самой команды короче на треть.
Т.е не используется благо есть PIC код. И как я уже говорил последний раз это было актуально при MS-DOS и прочих.

E>>>>1) Z80 и i8080 — это 16 битовые процессоры.
M>>>Да шо ви говорите?
E>>См выше. Я там уже все написал.
M>Ну, вообще-то мой сарказм относился в данном случае к выделенному утверждению
Еще раз, пожалуста прочти сначала несколько постов выше.

M>>>2) RISC набор команд как раз в 8бит влезает. Reduced Instruction Set вообще то по определению.
M>>>Сами опкоды? наверно. Так и у i8080 все опкоды в байт помещались.
E>>Опкоды и мелкие данные (до 4 бит).
M>Википедия с тобой не согласна
См выше, там есть пример 8 бит RISC.
Все современные RISC архитектуры имеют ограниченое и маленькое число команд.

Здравствуйте, eskimo82, Вы писали:

M>>Мало ли для чего ее придумали — на спектруме она во всю использовалась — команда работы с регистром — 4 такта, та же команда с памятью — семь тактов — почти в два раза замедление — думаешь, никто не использовал лишние регистры? А ПЗУ спектрумовское никто и не вызывал почти, там мало полезного было
E>Обработка IRQ подразумевала переключение страницы регистров. Ваш Кэп.

А пруф можно? Жаль всю литературу по Z80 выкинул, так бы сам уточнил. Никогда не встречал такой информации; сам активно использовал теневые регистры, никогда не сталкивался с необъяснимой их порчей, как было бы, если бы твое утверждение было верным. Переключение между наборами производится отдельной инструкцией, и все

M>>Абсолютные. По твоей же ссылке:
E>См. выше и научись читать уже же наконец.
Что я не прочел?


E>>>>Использовалось это все активно, и это позволяло не только экономить память, но и писать программы, которые сразу же штатно работают загруженными по любому адресу памяти, без всяких таблиц трансляции адресов.
E>>>Ну а можно было и с битовой табличкой патчить адреса — это в принципе до сих пор так и осталось, хотя использовалось в последний раз в DOS.
M>>Таблицы релокации есть и в PE, и используются, если что.
M>>Но только эту таблицу релокации надо тащить вместе с кодом, загружать, патчить — кому это надо? Плюс размер самой команды короче на треть.
E>Т.е не используется благо есть PIC код. И как я уже говорил последний раз это было актуально при MS-DOS и прочих.

Ты как-то непонятно и незаметно перепрыгнул с Z80 на x86

BZ>16-битные там от силы сложения подерживались. этим в общем-то и определяют 8 или 16-битный процессор
Ну давай ка вспомним что там еще кроме сложения было то ?

PS: Но я уже писал выше, что оговорился — процессор считался 8 битным с 8 разрядной шиной.

M>>>Мало ли для чего ее придумали — на спектруме она во всю использовалась — команда работы с регистром — 4 такта, та же команда с памятью — семь тактов — почти в два раза замедление — думаешь, никто не использовал лишние регистры? А ПЗУ спектрумовское никто и не вызывал почти, там мало полезного было
E>>Обработка IRQ подразумевала переключение страницы регистров. Ваш Кэп.

M>А пруф можно? Жаль всю литературу по Z80 выкинул, так бы сам уточнил. Никогда не встречал такой информации; сам активно использовал теневые регистры, никогда не сталкивался с необъяснимой их порчей, как было бы, если бы твое утверждение было верным. Переключение между наборами производится отдельной инструкцией, и все

С пруфом посложнее, но вот например:

ЦП Z80 содержит два альтернативных блока регистров: главный (A-L) и вспомогательный
(A'-L'). С точки зрения программиста оба блока абсолютно равноправны, но в данный момент
можно работать лишь с одним из них. Переключение этих блоков производится командами ЕХХ и
EX AF.AF'. Такая организация удобна тем, что позволяет быстро сохранить содержимое
регистровых блоков при вызове подпрограмм или при возникновении прерывания. Однако
следует помнить: отсутствует средство подтверждения, какой из блоков (главный или
вспомогательный) используется в данный момент.

M>>>Абсолютные. По твоей же ссылке:
E>>См. выше и научись читать уже же наконец.
M>Что я не прочел?
То что ты не прочел.

M>>>Таблицы релокации есть и в PE, и используются, если что.
M>>>Но только эту таблицу релокации надо тащить вместе с кодом, загружать, патчить — кому это надо? Плюс размер самой команды короче на треть.
E>>Т.е не используется благо есть PIC код. И как я уже говорил последний раз это было актуально при MS-DOS и прочих.
M>Ты как-то непонятно и незаметно перепрыгнул с Z80 на x86
Не ты ли написал 3мя строками выше про PE формат ? С моей стороны я всего лишь уточнил что сейчас битовая табличка не используется.

Здравствуйте, eskimo82, Вы писали:

M>>То-то на ARM'е всякие Thumb'ы прикручивать стали
E>Thumb — это тяжелое 16 битовой наследие. Сейчас его никто не использует.

Ну, наследие не такое уж старое. Thumb2 в 2003 гожу сделали. И вполне активно используется, во всяких встраиваемых недомерках:

Thumb -ориентированные ядра и их развитие

Высокая производительность, великолепная плотность кода

Рынок встраиваемого управления обслуживается в настоящее время 8 и 16-разрядными приборами от большого количества поставщиков. Однако, в перспективных применениях с высокими функциональными возможностями, эти приборы часто не обеспечивают требуемой производительности. Вот почему для таких применений необходима 32-разрядная производительность процессоров RISC, объединенная с высокой плотностью кода, характерной для 16-разрядных процессоров CISC. Технология Thumb обеспечивает обе эти потребности, наводя мосты между 16-разрядными системами и завтрашними 32-разрядными системами.

Здравствуйте, eskimo82, Вы писали:

E>>>>>1) Z80 и i8080 — это 16 битовые процессоры.
M>>>>Да шо ви говорите?
E>>>См выше. Я там уже все написал.
M>>Ну, вообще-то мой сарказм относился в данном случае к выделенному утверждению
E>Еще раз, пожалуста прочти сначала несколько постов выше.

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

E>См выше, там есть пример 8 бит RISC.
E>Все современные RISC архитектуры имеют ограниченое и маленькое число команд.

Ты об этом что ли — Natalius 8 bit RISC?

Ну, процитирую вики еще раз, если ты не прочитал

Нередко слова «сокращённый набор команд» понимаются как минимизация количества инструкций в системе команд. В действительности, инструкций у многих RISC-процессоров больше, чем у CISC-процессоров.[6][7] Некоторые RISC-процессоры вроде транспьютеров фирмы INMOS (англ.) имеют наборы команд не меньше, чем, например, у CISC-процессоров IBM System/370; и наоборот — CISC-процессор DEC PDP-8 имеет только 8 основных и несколько расширенных инструкций.
На самом деле, термин «сокращённый» в названии описывает тот факт, что сокращён объём (и время) работы, выполняемый каждой отдельной инструкцией — как максимум один цикл доступа к памяти, — тогда как сложные инструкции CISC-процессоров могут требовать сотен циклов доступа к памяти для своего выполнения.[8]
Некоторые архитектуры, специально разработанные для минимизации количества инструкций, сильно отличаются от классических RISC-архитектур и получили другие названия: Minimal instruction set computer (MISC), Zero instruction set computer (ZISC), Ultimate RISC (также называемый OISC), Transport triggered architecture (TTA) и т. п.

M>>>То-то на ARM'е всякие Thumb'ы прикручивать стали
E>>Thumb — это тяжелое 16 битовой наследие. Сейчас его никто не использует.

M>Ну, наследие не такое уж старое. Thumb2 в 2003 гожу сделали. И вполне активно используется, во всяких встраиваемых недомерках:
Нет, не пользуются. а) геморно б) нет смысла. Шлепают какую нибудь простенькую микруху аля stm и не парятся.

M>

M>Thumb -ориентированные ядра и их развитие
M>Высокая производительность, великолепная плотность кода
M>Рынок встраиваемого управления обслуживается в настоящее время 8 и 16-разрядными приборами от большого количества поставщиков. Однако, в перспективных применениях с высокими функциональными возможностями, эти приборы часто не обеспечивают требуемой производительности. Вот почему для таких применений необходима 32-разрядная производительность процессоров RISC, объединенная с высокой плотностью кода, характерной для 16-разрядных процессоров CISC. Технология Thumb обеспечивает обе эти потребности, наводя мосты между 16-разрядными системами и завтрашними 32-разрядными системами.

А цитата уже давно устарела, еще из прошлого века похоже.

E>>>>>>1) Z80 и i8080 — это 16 битовые процессоры.
M>>>>>Да шо ви говорите?
E>>>>См выше. Я там уже все написал.
M>>>Ну, вообще-то мой сарказм относился в данном случае к выделенному утверждению
E>>Еще раз, пожалуста прочти сначала несколько постов выше.
M>Я всю ветку прочитал, ты можешь конкретно сказать, к какому посту ты меня отсылаешь?
Ровно к следующему, после того что ты процитировал.

E>>См выше, там есть пример 8 бит RISC.
E>>Все современные RISC архитектуры имеют ограниченое и маленькое число команд.
M>Ты об этом что ли — Natalius 8 bit RISC?
Это про 8 бит.

M>Ну, процитирую вики еще раз, если ты не прочитал
M>

Нередко слова «сокращённый набор команд» понимаются как минимизация количества инструкций в системе команд. В действительности, инструкций у многих RISC-процессоров больше, чем у CISC-процессоров.[6][7] Некоторые RISC-процессоры вроде транспьютеров фирмы INMOS (англ.) имеют наборы команд не меньше, чем, например, у CISC-процессоров IBM System/370; и наоборот — CISC-процессор DEC PDP-8 имеет только 8 основных и несколько расширенных инструкций.
M>На самом деле, термин «сокращённый» в названии описывает тот факт, что сокращён объём (и время) работы, выполняемый каждой отдельной инструкцией — как максимум один цикл доступа к памяти, — тогда как сложные инструкции CISC-процессоров могут требовать сотен циклов доступа к памяти для своего выполнения.[8]
M>Некоторые архитектуры, специально разработанные для минимизации количества инструкций, сильно отличаются от классических RISC-архитектур и получили другие названия: Minimal instruction set computer (MISC), Zero instruction set computer (ZISC), Ultimate RISC (также называемый OISC), Transport triggered architecture (TTA) и т. п.

Еще раз тогда отвечу: Во всех RISC сейчас число инструкций гораздо меньше чем в CISC. Слово Reduced следует понимать буквально и в плане количества команд.

Здравствуйте, eskimo82, Вы писали:

M>>А пруф можно? Жаль всю литературу по Z80 выкинул, так бы сам уточнил. Никогда не встречал такой информации; сам активно использовал теневые регистры, никогда не сталкивался с необъяснимой их порчей, как было бы, если бы твое утверждение было верным. Переключение между наборами производится отдельной инструкцией, и все

E>С пруфом посложнее, но вот например:

	Скрытый текст
	E> ЦП Z80 содержит два альтернативных блока регистров: главный (A-L) и вспомогательный E>(A'-L'). С точки зрения программиста оба блока абсолютно равноправны, но в данный момент E>можно работать лишь с одним из них. Переключение этих блоков производится командами ЕХХ и E>EX AF.AF'. Такая организация удобна тем, что позволяет быстро сохранить содержимое E>регистровых блоков при вызове подпрограмм или при возникновении прерывания. Однако E>следует помнить: отсутствует средство подтверждения, какой из блоков (главный или E>вспомогательный) используется в данный момент.

Ну да, все так. Позволяет — хочешь — сохраняй, не хочешь — не сохраняй. Аппаратных ограничений никаких нет. Сам так и делал — при вызове подпрограммы переключаешься на альт регистры, и с ними работаешь. Гораздо быстрее, чем сохранять на стеке. Единственно, нужно было помнить, какие подпрограммы их используют, вот и все. ПЗУ, насколько я помню, вроде их не портило.

M>>>>Абсолютные. По твоей же ссылке:
E>>>См. выше и научись читать уже же наконец.
M>>Что я не прочел?
E>То что ты не прочел.
Можно все же конкретно привести, что я упустил?

E>Не ты ли написал 3мя строками выше про PE формат ? С моей стороны я всего лишь уточнил что сейчас битовая табличка не используется.

Ну ты про ДОС заикнулся, это уже x86 в любом случае. Если я конечно правильно понял, и имелся в виду MS-DOS, а не TR-DOS

Здравствуйте, eskimo82, Вы писали:

M>>>>То-то на ARM'е всякие Thumb'ы прикручивать стали
E>>>Thumb — это тяжелое 16 битовой наследие. Сейчас его никто не использует.

M>>Ну, наследие не такое уж старое. Thumb2 в 2003 гожу сделали. И вполне активно используется, во всяких встраиваемых недомерках:
E>Нет, не пользуются. а) геморно б) нет смысла. Шлепают какую нибудь простенькую микруху аля stm и не парятся.

Ок, сейчас не используется. Но ты же не будешь отрицать, что thumb затеяли, чтобы увеличить плотность кода, которая была хуже, чем у x86?

Здравствуйте, eskimo82, Вы писали:

E>Еще раз тогда отвечу: Во всех RISC сейчас число инструкций гораздо меньше чем в CISC. Слово Reduced следует понимать буквально и в плане количества команд.

Ок. Допустим. Что тогда ты подразумеваешь под инструкцией в RISC?
Насколько я помню, у RISCа как-то так каждая команда кодируется (по крайней мере, у АРМа):
[Флаги условий][КОП][Ист1][Ист2][Рез-т][Еще какая-то фингя 1][Еще какая-то фингя 2]...
И все это имеет фиксированный размер — т.е. нет никакой переменной длины команд. Что из этого влезает в 8 бит?
И частенько эти команды содержат неиспользуемые поля, которые в CISC x86 убрали бы, укоротив инструкцию, за счет чего в x86 плотность кода была выше.

Здравствуйте, eskimo82, Вы писали:

N>>Смотрим на какой-нибудь ARM и видим возможность and/or со значением типа "сдвинуть константу 1 на указанное число бит".
E>Например, такую команду ?

Я же сказал — and, or. Также eor, bic. Вообще-то и арифметика тоже годится. Константа формируется из базового значения и сдвига для образования финальной константы.

N>>А вообще очень прошу объяснить, почему это вдруг такие команды стали "мрачными отголосками CISC".
N>>Накойхер (tm) требовать переводить в цепочку "загрузить 1 — сдвинуть — выполнить операцию" то, что элементарно выполняется в пределах одной команды чуть более продвинутым железом?
E>Так никто не делает.

Такие утверждения требуют доказательства. Особенно когда видно противоположное.

N>>Или Вы по-прежнему в рамках ложной парадигмы "RISC это когда очень мало разных команд"?
E>>>История уже поставила все точки на i.
N>>Я боюсь, что она поставила немного не те точки, чем вы
E>Я не являюсь историей.

Метко подмечено. Ну а если попробовать всё-таки распарсить моё предложение?

E>>>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.
N>>А покажите. Какой-нибудь код общего назначения типа qsort.
E>Покажу, но позже.

Ну, ждём. А пока что не вижу смысла верить на слово.

Здравствуйте, eskimo82, Вы писали:

N>>Идея CISC не отвергнута именно потому, что её можно проконвертировать
N>>Зато только за счёт конструкции системы команд CISC допускает неограниченное развитие, а RISC — нет. Вон через VEX префикс добавили ещё один аргумент командам. Как ты такое сделаешь на RISC?
E>Гипотетическое неограниченое развитие системы команд никому не нужно.

Боюсь, Intel с этим не согласен. Почти каждый год они добавляют что-то новенькое, сохраняя старое со всеми его спецификами. Вон даже в 64-битном коде отдельный байт верхнего уровня на какое-то нелепое "mov al,imm8", а рядом новые суперкоманды.

N>>Вот если они подойдут к порогу остановки — тогда начнётся поиск альтернатив. Собственно, он уже ведётся — каждый следующий техпроцесс сложнее вытягивать. Но покажите мне ARM с аналогом AVX2?
E>В расширениях ARM есть векторные инструкции и уже довольно давно (еще со времен StrongARMа — это 2003 год примерно).

Я просил аналог именно AVX2 (ну ладно, можно и просто AVX), а не вообще "векторные инструкции", реализуемые, BTW, как обращение к сопроцессору (что резко смягчает требования к умещению в прокрустово ложе стандартного конвейера). И как они влезут в существующее пространство команд? Заведёте ещё один номер сопроцессора?

N>>Reduced в RISC не потому, что команд мало или они короткие, а потому, что они простые. Никаких сложностей стиля mov ofs(%7), @(%2)+ в PDP-11. Всё исполнение должно уложиться на стандартные 5 тактов (в среднем по архитектурам). При этом ничто не мешает создать 100500 команд под каждый тонкий частный случай.
E>Как правило, команд мало. Конкретно для ARM — 1 команда (любая) занимает 0.5 такта.

Полтакта на команду — Вы эту демагогию оставьте младшей группе ясель, а мы вроде тут взрослые люди. Речь не про суммарный throughput в пересчёте на команду, а про длительность отработки каждой команды от посылки запроса на чтение из памяти до финальной фиксации результатов.
И про мало команд — не надо смешить. Фактически с точки зрения CISC каждая из ARM'овских вариаций — условие выполнения, менять/нет CC, значение сдвига для op2 есть или нет — создаёт новую ось пространства команд. В результате там, где в CISC, грубо говоря, 100 команд, в RISC типа ARM их получается несколько тысяч.

N>>>Идея CISC не отвергнута именно потому, что её можно проконвертировать
N>>>Зато только за счёт конструкции системы команд CISC допускает неограниченное развитие, а RISC — нет. Вон через VEX префикс добавили ещё один аргумент командам. Как ты такое сделаешь на RISC?
E>>Гипотетическое неограниченое развитие системы команд никому не нужно.
N>Боюсь, Intel с этим не согласен. Почти каждый год они добавляют что-то новенькое, сохраняя старое со всеми его спецификами. Вон даже в 64-битном коде отдельный байт верхнего уровня на какое-то нелепое "mov al,imm8", а рядом новые суперкоманды.
Ваши "боюсь" мне совсем не интересны. Intel делает то что хочет — это его право.

N>>>Вот если они подойдут к порогу остановки — тогда начнётся поиск альтернатив. Собственно, он уже ведётся — каждый следующий техпроцесс сложнее вытягивать. Но покажите мне ARM с аналогом AVX2?
E>>В расширениях ARM есть векторные инструкции и уже довольно давно (еще со времен StrongARMа — это 2003 год примерно).
N>Я просил аналог именно AVX2 (ну ладно, можно и просто AVX), а не вообще "векторные инструкции", реализуемые, BTW, как обращение к сопроцессору (что резко смягчает требования к умещению в прокрустово ложе стандартного конвейера). И как они влезут в существующее пространство команд? Заведёте ещё один номер сопроцессора?
Вам и привели технологию по смыслу аналогичную AVX2. Векторная арифметика логически реализуется одельным сопроцессором, в ARM их может быть до 16 штук. Физически это может быть тот же самый кристал с тем же 0.5 такта на команду.

N>>>Reduced в RISC не потому, что команд мало или они короткие, а потому, что они простые. Никаких сложностей стиля mov ofs(%7), @(%2)+ в PDP-11. Всё исполнение должно уложиться на стандартные 5 тактов (в среднем по архитектурам). При этом ничто не мешает создать 100500 команд под каждый тонкий частный случай.
E>>Как правило, команд мало. Конкретно для ARM — 1 команда (любая) занимает 0.5 такта.
N>Полтакта на команду — Вы эту демагогию оставьте младшей группе ясель, а мы вроде тут взрослые люди. Речь не про суммарный throughput в пересчёте на команду, а про длительность отработки каждой команды от посылки запроса на чтение из памяти до финальной фиксации результатов.
Это не демагогия, а факт. Понятно, что когда нечем аргументировать некоторые личности вспоминают про "младшую групу ясель". Сумарное время зависит от конкретного железа, наличия и отсутсвия кешей и много другого, точно также как и дляч платформы x86.

N>И про мало команд — не надо смешить. Фактически с точки зрения CISC каждая из ARM'овских вариаций — условие выполнения, менять/нет CC, значение сдвига для op2 есть или нет — создаёт новую ось пространства команд. В результате там, где в CISC, грубо говоря, 100 команд, в RISC типа ARM их получается несколько тысяч.
Вы говорите абсолютную чушь. Армовская команда — одна и в ней указывается то что нужно сделать, как, и в каком случае. При CISC подходе для этого требуется 100500 различных команд — различные проверки статусных битов, команды условного перехода и многое другое.

M>Ок. Допустим. Что тогда ты подразумеваешь под инструкцией в RISC?
M>Насколько я помню, у RISCа как-то так каждая команда кодируется (по крайней мере, у АРМа):
M>[Флаги условий][КОП][Ист1][Ист2][Рез-т][Еще какая-то фингя 1][Еще какая-то фингя 2]...
M>И все это имеет фиксированный размер — т.е. нет никакой переменной длины команд. Что из этого влезает в 8 бит?
M>И частенько эти команды содержат неиспользуемые поля, которые в CISC x86 убрали бы, укоротив инструкцию, за счет чего в x86 плотность кода была выше.
Будь добр, прежде чем задавать глупые вопросы, ознакомся с приведенным выше примером 8 битного RISC. Там есть и опкоды и как это работает.

N>>>Смотрим на какой-нибудь ARM и видим возможность and/or со значением типа "сдвинуть константу 1 на указанное число бит".
E>>Например, такую команду ?
N>Я же сказал — and, or. Также eor, bic. Вообще-то и арифметика тоже годится. Константа формируется из базового значения и сдвига для образования финальной константы.
Приведи пожалуста конкретный пример в ассемблерном коде, что бы разговор был более предметным.

N>>>А вообще очень прошу объяснить, почему это вдруг такие команды стали "мрачными отголосками CISC".
N>>>Накойхер (tm) требовать переводить в цепочку "загрузить 1 — сдвинуть — выполнить операцию" то, что элементарно выполняется в пределах одной команды чуть более продвинутым железом?
E>>Так никто не делает.
N>Такие утверждения требуют доказательства. Особенно когда видно противоположное.
Для начала, будь добр, приведи доказательство предыдущего своего утверждения.

N>>>Или Вы по-прежнему в рамках ложной парадигмы "RISC это когда очень мало разных команд"?
E>>>>История уже поставила все точки на i.
N>>>Я боюсь, что она поставила немного не те точки, чем вы
E>>Я не являюсь историей.
N>Метко подмечено. Ну а если попробовать всё-таки распарсить моё предложение?
Ваше предложение распарсено. Оно не соотвесвует истине, ибо противоречит фактам. Точка.

E>>>>Мне не надо напомнинать про 32К памяти — я все прекрасно помню. CISC подход наоборот увеличивает размер программы. Сравните код x86 и ARM32, будете удивлены.
N>>>А покажите. Какой-нибудь код общего назначения типа qsort.
E>>Покажу, но позже.
N>Ну, ждём. А пока что не вижу смысла верить на слово.
Не хотите — не верте — я вас не заставляю.