Архитектрура системы команд 8-разрядного МК, Оценка/Анализ/Архитектура 8-32 разрядного МК Опции

[vitja]

Передо мной поставлена задача (сам напросился) - дать предложения по архитектуре
системы команд 8-разрядного процессорного ядра для управления работой аппаратуры SOC,
совместимой с ЯВУ, удобной для программирования на ассемблере, простой в реализации
и обеспечивающей компактный программный код и малое число тактов на его выполнение.

Я, как учили в институте, сперва посмотрел, что делают другие, провел оценку того, что у них получилось по затратам кода
и тактов на его выполнение для типовых задач управления.

Потом, как учили в аспирантуре, провел анализ влияния особенностей системы команд процессора
на его эффективность rating.pdf
http://moko.ru/mc/


Затем поступил не так, как учили, и вместо того, чтобы взять за основу архитектуру известного МК,
предложил концепт "простого" 8-разрядного процессорного ядра на базе стековой архитектуры,

который позволяет обрабатывать данные до 32-разрядов и не только на стеке, но и в памяти,
задавать в байтовой команде сколь угодно длинные поля констант и адресов,
и еще некоторые рюшечки и фишечки (там же M8.zip) плюс заявка на патент ......2008.

Концепт получился приемлемый, если сравнивать с 8051, PIC, AVR и даже ARM Thumb, но не идеальный:

1. Есть сомнения в правильности методики оценки эффективности процессора,
и, соответственно, принятых решений. Возможно есть другие, которые приведут к другим решениям.

2. Из него (концепта) торчат уши PICа - страничная организация памяти, что не позволяет обеспечить линейный доступ к данным,
AVRровские регистры косвенной адресации, а не механизм адресации данных по ссылкам и пр.
Переходить на 32-разрядный формат команды не позволяет постановка задачи, а решить эти проблемы,
оставаясь в рамках 8-разрядной системы команд у меня пока не получается.

Люди добрые, посмотрите хотя бы по диагонали moko.ru/mc и помогите "бедному" разработчику, кто чем может по делу,
без ля-ля-ля, смайликов и спама, - советом, предложением, позитивной критикой и замечаниями. Не дайте загинуть концепту.

Сообщение отредактировал vitja - Jan 16 2009, 12:07

[Mahagam]

ага, мусье vitja перебрался сюда с хобота, где его "изыскания" также "неоценили"

на зачем тут повторять бред из PC Week предварительно не обдумав цифры? вы там так и не придумали - где оставшиеся 70% рынка?

Примеры ? Ваш и мой ?пень? вырос из 8086-го (1980 год), была даже его 8-разрядная версия (это ближе к теме).
вы знаете, мне очень хочется узнать, что за такая "8-разрядная версия" была у 8086 ? или это вы в порыве графоманства не закусили?

Итого имеем 2.0*0.73*1.0*1.15 = 1.7. Во столько раз с точностью достаточной
для практического применения МК430 уступает 8051.
ооох! ну и забористая трава! эк вы, Маэстро, быстро и точно оценили MSP430. а ничего, что http://mcu.caxapa.ru/benchmarks/ получается с точностью до наоборот? ну неиначе - во всём виноваты компиляторы!

да, MSP430 иногда выполняет команду длительностью аж (о боже!) целых 6 (шесть) тактов. но вы так и не удосужились понять, что за этим стоит, для какого случая это получается крайне эффективно, и сколько команд 8051 ядра нужно выполнить, чтобы произвести такое же действие.
но вы просто решили, что MSP430 - это такое неэффективное ядро. аж в 1.7 раза хуже чем 8051, а мысли о том, что все ваши наукообразные рассуждения и вычисления эффективности с точностью до сотых - бред, не приходило?

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

ну так что, будем учится, или убежим на следующий форум? где, может быть, "оценят"

[vitja]

1///ага, мусье vitja

2/// мне очень хочется узнать, что за такая "8-разрядная версия" была у 8086 ? или это вы в порыве графоманства не закусили?

3///да, MSP430 иногда выполняет команду длительностью аж (о боже!) целых 6 (шесть) тактов.

будем учится

1 Здравствуй дорогой/ Рад снова встретится/хоть и с детства не люблю ябед/ однако на iXBT уже все закончилось
2 Intel 8088
3 AVR с ARMом в придачу выполняет команду за один такт/ Счет 6/1 в чью пользу?
Просьба сохранять толерантность в общении/ задавать вопросы или ответы на них/ от смайликов Вы уже отучились/ Молодец

[GetSmart]

3 AVR с ARMом в придачу выполняет команду за один такт/ Счет 6/1 в чью пользу?

Теоретик
ARM выполняет команду группового сохранения регистров во внутренней раме за 17 тактов максимум, а ту же команду во внешней раме до 100 тактов (а то и более), в зависимости от настроек внешней шины.

8088 - 16 битный проц с внешней 8р шиной. Система команд и архитектура 16-битные.

[vitja]

Теоретик
ARM выполняет команду группового сохранения регистров во внутренней раме за 17 тактов максимум, а ту же команду во внешней раме до 100 тактов (а то и более), в зависимости от настроек внешней шины.

8088 - 16 битный проц с внешней 8р шиной. Система команд и архитектура 16-битные.

Кто бы спорил/ Особенно по последнему/
Это приведено как пример того что даже ХХ86 не гнушался 8-разрядности и 8-разрядные МК рановато списывать в утиль

А про команду группового сохранения - это верно - сохранить 16 регистров во внутренней памяти быстрее не получается/плюс такт на команду
Вопрос вот в чем - а нужна ли эта команда?
Для переключения контекста/ Как часто это присутствует в программе простого 8-разрядного МК/
При прерываниях/ Мультизадачность - для МК это экзотика/
Далее задаем долю операций переключения контекста/ 1% мало - берем 2/ В результате мы сэкономили на этой команде в объеме кода 0.32%
В тактах не выиграли ничего/ Зато усложнили аппаратуру/ Ради чего

Вами поднят гораздо более глубокий вопрос - касающийся состава команд и его влияния
на объем программного кода и тактов на его выполнение../Брр
Если уж вводить сложные команды, то какие -
мне кажется это не команды групповой пересылки регистров.
Большую долю операторов ЯВУ составляют условные операторы (16%) и циклы - 18%
(более всего счетные). Проценты в разумных пределах можно поправить.
Из этого следует, что надо объединить в одной команде операцию тестирования операндов
и перехода по условию, надо объединить модификацию счетчика с переходом по условию
в начало цикла. Здесь экономия памяти и тактов посущественнее будет.
Однако в каком МК вы это видели. Скажите.

Сообщение отредактировал vitja - Jan 19 2009, 13:42

[Mahagam]

Это приведено как пример того что даже ХХ86 не гнушался 8-разрядности и 8-разрядные МК рановато списывать в утиль

ну и бред. 8-разрядная внешняя шина позволяла в те годы зверски уменьшить цену конечного изделия на этом процессоре, оставаясь в рамках 16-ти разрядной вычислительной мощности. откуда взялась связь с МК - неясно.

А про команду группового сохранения - это верно - сохранить 16 регистров во внутренней памяти быстрее не получается/плюс такт на команду
Вопрос вот в чем - а нужна ли эта команда?

не. разработчики ядра её так просто по приколу вставили. ага.

Мультизадачность - для МК это экзотика/

да-да! и всякие табуны uCOS, eCOS, FreeFTOS, CTL и прочих многозадачных примочек - это всё из области экзотики и фантазии.
конечно, раз этого не было в книжках двадцатилетней давности, то этого просто не может быть сейчас.

Далее задаем долю операций переключения контекста/ 1% мало - берем 2/ В результате мы сэкономили на этой команде в объеме кода 0.32%
В тактах не выиграли ничего/ Зато усложнили аппаратуру/ Ради чего

ой жжошь!
"1% мало - берём 2" а почему не 5 ? почему не 10? а в военное время и до 80 может подскочить!
а подумать, в какий процессорах есть команды такого типа, а в каких нет? и что даёт эта команда? а зачем такую команду ввели 80286 проц? а что она давала там?

[vitja]

ну и бред. откуда взялась связь с МК - неясно.

разработчики AТMEL так просто по приколу вставили команду группового сохранения регистров/

жжошь!
а зачем такую команду ввели 80286 проц? а что она давала там?

Только как пример того/ что 16-разрядный процессор 8086 работал на 8-разрядной шине как и современные 8-разрядные МК/

Они приколись по полной - ввели команду группового восстановления регистров/
в 80286 эти команды ввели без приколов/ а по причине необходимости поддержки мультизадачности

Типовой МК работает с таймером (1 обработчик прерывания) плюс интерфейсы (еще 1 или более обработчиков)
В каждом из них сохраняют контекст одной или большим числом команд/ Доля этих команд в общем объеме кода
программы минимальна и даже в военное время не превышает 2%/ Как сделать больше я не знаю / Научите

Сообщение отредактировал vitja - Jan 19 2009, 14:46

[Mahagam]

Только как пример того/ что 16-разрядный процессор 8086 работал на 8-разрядной шине как и современные 8-разрядные МК/

да вы просто из страны эльфов! откуда вам знать какой разрядности и сколько шин внутрях у МК? это внешняя шина имеет ограничения по разрядности. что там внутрях - известно только производителям. внутрях кристалла к ядру может подходить а) 8-ти разрядная шина команд б) 8-и разрядная шина данных из памяти в) 8-и разрядная шина данных для записи в память. в итоге за 1 такт мы а) читаем команду б) получаем данные из памяти в) пишем результат предыдущих вычислений в память. МК остаётся 8-и разрядным. но эти его 8 разрядов ничего общего с внешними 8-ю разрядами 8086 не имеют. ибо по внешней шине за 1 такт происходит только одна транзакция.

Они возможно по приколу/ а в 80286 по причине необходимости поддержки мультизадачности

это вы высосали из пальца. что бы вы не сосали что-нибудь ещё, приведу пример.
пример прост: имеем понятное ограничение - одно обращение к памяти за такт (память - внешняя). имеем задачу - сохранить в стеке 10 регистров
вариант а) 10 раз мы читаем команду PUSH, 10 раз пишем в стек. итого 10 байт кода, 20 обращений к памяти
вариант б) 1 раз прочитали PUSHALL, 10 раз записали в стек. итого - 1 байт кода, 11 обращений к памяти.
эффективно? безусловно. но эта команда становится эффективной по скорости только в случае если данные и команды лежат в одной физической памяти. в случае с МК это уже не так критично.

Типовой МК работает с таймером (1 обработчик прерывания) плюс интерфейсы (еще 1 или более обработчиков)
В каждом из них сохраняют контекст одной или большим числом команд/ Доля этих команд в общем объеме кода
программы минимальна и даже в военное время не превышает 2%/ Как сделать больше я не знаю / Научите

а если на процессор валятся 20000 прерываний в секунду? если он из одного прерывания еле успевает переползать в обработчик следущего? есть ли смысл оптимизировать ядро для быстрого сохранения/восстановления контекста?
ARM7 умеет сохранять в стек одной командой произвольные регистры, что не только полезно в обработчике прерываний, но и просто при вызове функций.

[vitja]

1 пример прост: а) 10 раз мы читаем команду PUSH, 10 раз пишем в стек. итого 10 байт кода, 20 обращений к памяти
вариант б) 1 раз прочитали PUSHALL, 10 раз записали в стек. итого - 1 байт кода, 11 обращений к памяти.

2 ARM7 умеет сохранять в стек одной командой произвольные регистры, что полезно ... при вызове функций.

1. Я тоже иногда ошибаюсь и передергиваю понятия.
Однако при разделенных шинах команд и данных (в МК, как правило, это так)
Мы будем иметь 10 команд PUSH и только 10 тактов на их выполнение, а Вас почему то 11. Неувязочка получилась.

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

Однако на этот вопрос ответил заранее GetSmart - поэтому не напрягайтесь, от 3 до 10, ++++
(в среднем можно принять 5 туда и 5 обратно при каждом вызове процедуры доля которых в среднем составляет 18%)
Срочно делаю перерасчет числа тактов для AVR.

Сообщение отредактировал vitja - Jan 19 2009, 18:03