Архитектрура системы команд 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

[vvvv]

Ну все верно, Вы говорите, что рынок занимают, что место не уступят. Вот только смысл этой эффективности теряется среди других вещей.
Вы пишете, давайте обсуждать эффективность ядра процессора. Смысл обсуждать эффективность ядра, если другие компоненты микропроцессора
завалят эту эффективность в два счета. Как к примеру обсуждать эффективность применения аспирина утром или вечером, что эффективнее, принять
его в 9.15 утра, или 17.15 вечера, и все это в приложении к алкашу. Нет смысла, для его здоровья гораздо эффективнее бросить пить.
Также и здесь умозрительная задача, обсуждать ради обсуждения, без какого нибудь практического выхода в обозримом будущем.
Какой смысл обсуждать эффективность структуры команд, если повышение тактовой с 8 МГц до 16МГц, на любой платформе дает прирост в 200%,
против эффективности структуры команд, которая в предельном случае даст прирост 23%.
Поэтому с практической точки зрения, обоснуйте, хотя бы теоретически, какой выигрыш даст Ваша тема, хотя бы виртуально, чего не достичь
другими методами, там повышением частоты, переходом на другую технологию чипов или еще как то. Тогда хоть будет интересно обсуждать.

[vitja]

... Ну все верно, Какой смысл обсуждать эффективность структуры команд, если повышение тактовой с 8 МГц до 16МГц, на любой платформе дает прирост в 200%, ......
против эффективности структуры команд, которая в предельном случае даст прирост 23%.

"Обсуждать эффективность структуры команд" стоит хотя бы по по трем причинам ... о чем я говорил ранее давно и не буду повторяться.

А вот вера в прогресс техники - удвоить тактовую частоту или перейти на технологию 0ю13 мк - это другое.
Почему. Удвоение частоты приведет к удвоению потребления. Переход с 0.18 мк на 0.13 занял много лет и еще больше денег, хорошо что не наших.
Так или нет.
Я утверждаю в http://moko.ru/mc/ (таблица) 32, что система команд оказывает существенное влияние на эффективность МК (в попугаях).
И эта эффективность отличается не на 23%, а в два и даже три раза.

:
http://www.atmel.com/dyn/resources/prod_do...nts/doc3323.pdf

Я думаю так - длина команды д.б. в районе 11-12 бит.

1. Первый абзац это самое правильное, что я здесь видел.
Пример для всех.
Будьте кратки, при возможности давайте ссылки на первоисточник.

Ответ.
Из указанного материала я понял, что кроме двух известных древних проффессий, есть третья - аналитики (прогнозисты).
Из ссылки - "аналитическая компания Semico в 200ю году предсказала для фирмы Atmel, что к 2007(8) году
32-разрядные МК будут преобладать на рынке"

Из PC Week от 5 декабря 2008
доля рынка МК
"14% 8051
12% PIC
3% AVR
1% ARM . Остальные места занимают другие фирмы со своими проприентарными процессорами (Motorola, Zilog, Holtek, Sani...)
По прогнозу аналитической компании Semico к 2010 году дC

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

[GetSmart]

Из PC Week от 5 декабря 2008
доля рынка МК
"14% 8051
12% PIC
3% AVR
1% ARM . Остальные места занимают другие фирмы со своими проприентарными процессорами (Motorola, Zilog, Holtek, Sani...)
По прогнозу аналитической компании Semico к 2010 году доля рынка 32-разрядных МК удвоится
за счет сокращения доли 16-разрядных МК (для ARM до 2%),
а рынок 8-разрядных МК сохранит свой объем".

Даже если это так (хотя я сильно сомневаюсь), то большая доля 8-битных контроллеров обусловлена привязанностью к уже написанному ПО. Из этого совершенно не следует, что будет востребована новая архитектура 8-битных контроллеров. 8-битники - прошлый век. Давайте ещё АВМ реанимируем
Я просмотрел PDF не очень подробно и заметил только совершенно непонятные (неадекватные) цифры в таблицах. Особенно удивила таблица со стоимостью МК (архитектуры). Сравнивите к примеру AVR и ARM со флэшем хотя бы 64К и удивитесь сколько необъективности в вашем PDF. Буквально по каждой таблице можно долго спорить, но не буду. Жалко своё время.

Кроме этого, есть много способов поднятия быстродействия микроконтроллера. Те же AVR при желании Atmel-a можно было бы ускорить в 4-6 раз не переделывая систему команд. Но почему-то это не делается. Может для 8-битников такая скорость и не требуется.

[vitja]

1) .... большая доля 8-битных контроллеров обусловлена привязанностью к уже написанному ПО

2) Я просмотрел PDF не очень подробно и заметил только совершенно непонятные (неадекватные) цифры в таблицах.
... Жалко своё время.

3) .... Те же AVR при желании Atmel-a можно было бы ускорить в 4-6 раз не переделывая систему команд. Но почему-то это не делается. Может для 8-битников такая скорость и не требуется.

Уже поздно.
Из всего отмеченного только по п.2 (по другим завтра)

2. Спасибо, что прочитали. На цифры не обращайте внимания. Статистика может обосновать все,
есть законы о нормальном распределении, есть выводы теории погрешностей ....
Поэтому цифры можно перепроверять и пересчитывать, но зачем. Важны полученные оценки.
Объем кода (табл.32) при обработке данных 8-32 разряда:
AVR 8051 ARM M8
3.3 2.4 2.0 1.0

И еще личная просьба.
Не пожалейте еще немного своего времени, раз уж посмотрели PDF.
Скажите про Ваше отношение к цифрам в таблице 19 (глава 4), где приведены доли типовых машинных операций
на реализацию операторов ЯВУ.

Всем спокойной ночи.

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