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

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

[zltigo]

а у Вас голая наука,

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

 

[vitja]

Как студенты ... так и ... аспиранты не занимаются "наукой" .
 

Практикам.
Вы используете продукты известных фирм от Intel до Атмел, и уверен, что грамотно.
Почему используете. Потому что доступно на каждом углу, стоит дешево и решает ваши задачи.
Как в Макдональдсе - гамбургер, фри и пепси (схема, компилятор, отладчик).
Нравится. Кушайте на здоровье.
Мне хочется другого.
Не 51-го с его многоформатной и переусложненной системой команд,
не PICа с его аккумулятором и ограниченным регистровым файлом,
и даже не AVR с его регистрами (об Эльбрусе не говорим - это не процессор для 8-разрядного микроконтроллера)
Чего хочу, попытался изложить вышше (там). Если недопонятно изложил. Виноват, поправьте.

Доцент

надо JAVA-процессор делать ... уже есть такие.

По существу вопроса - непонятна цель данной разработки. Нет цели, соответственно, нельзя поставить задачи и тем более найти пути их решения.

JAVA байт-код сложен для прямой интерпретации (реализации) в ограниченной аппаратуре МК.
А вот его его подмножество ....

О цели см. http://moko.ru/mc/ но там много цифирек и текста, поэтому надо вчитываться.
В 3-х словах о цели темы - эффективная система команд (МК)

Для чего - что бы ее сделать.

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

[zltigo]

Мне хочется другого.
Не 51-го с его многоформатной и переусложненной системой команд,
не PICа с его аккумулятором и ограниченным регистровым файлом,
и даже не AVR с его регистрами.

При этом, Вы якобы претендуя на реализацию

8-разрядного процессорного ядра для управления работой аппаратуры SOC

Совсем не поминаете именно реализации ядер по жизни заточенных под SoC.
Ведете разговоры о "..если сравнивать с 8051, PIC, AVR и даже ARM Thumb,". Даже "ARM Thumb" - а какого, черта якобы говоря о SoC поминать все это а не ARM Cortex-M1, NIOS... ? В бумажных переводных книжках такие буквы не встретились? "Наука", понимаш . Посмотрите на тот-же NIOS начала этого века и подумайте насколько и почему он отличается (и разрядностью, и системой команд, и количеством регистров) от поминаемых Вами "конкурентов" и бумажных проектов восьмидесятых годов прошлого века рождененных в 10мегагерцовые времена с ограничениями и на степень интеграции, и на количество ножек у DIP корпусов.

 

[vitja]

Ведете разговоры о "..если сравнивать с 8051, PIC, AVR и даже ARM Thumb,"...
Посмотрите на тот-же NIOS ....

Посмотрел NIOS. Это не гамбургер 8-разрядный - это биг-мак 32-разрядный.
16-битная 2-адресная регистровая система команд. Оченнь простая, 16 форматов, более полусотни команд, нет условных переходов, зато есть пропуски.
Чуть-чуть румянец навести и от системы команд ARM Thumb отличить невозможно. Но все равно от этой пищи....
Минус три балла.
И вообще. Я предложил конкретно специалистам -
обсудить только вопрос эффективности системы команд 8-разрядного процессора. Предложил методику, привел оценки, как смог, дал предложения по повышению этой самой эффективности.
Все. О RISC говорить перестали, о критериях эффективности МК тоже, теперь не будем говорить о 32-разрядных процессорах.
А если Вам не нравятся 8-разрядные МК, то ..... это Ваше дело.
Однако большую часть рынка микроконтроллеров занимают именно они и это место другим уступят не скоро.

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

[zltigo]

Посмотрел NIOS. Это не ...

Вопрос не Вашей оценки чего-либо а в том, что взявшись наукобразно судить о ядрах для SoC, и даже уже родив некий "трактат" Вы до сего момента не удосужились ознакомится с реальными игроками на рынке SoC. Про подумать про то, почему они такие я уже и не говорю . Вместо этого наукообразный обзор и цитирование бумажных изданий с 80x годов и "улучшение" ядер прошлого века. Про "критерии" оценок SoC ядер по той-же занимаемой площади (к тому-же высосанные из пальца еще в том-же прошлом веке) - это вообще дурдом.

Из PC Week от 5 декабря 2008

Есть еще масса интересных журналов типа Хакер и иже с ним.

доля рынка МК


14% 8051
12% PIC
3% AVR
1% ARM . Остальные места занимают другие фирмы со своими проприентарными процессорами (Motorola, Zilog, Holtek, Sani...)

Врут. На первом месте микроконтроллеры, котрые уже и те-же москвичи выбрасывают в мусорник после каждой поездки на метро и прочая "электроная пыль" на ценниках в магазинах, карточках, картриджах.... Так о чем лично Вы пытаетесь вещать? Если не забыли, то Вы собирались просветить на счет SoC ядер.

 

[vitja]

......это вообще дурдом.

Врут. На первом месте микроконтроллеры, котрые уже и те-же москвичи выбрасывают в мусорник
...Если не забыли, то Вы собирались просветить ...
 

1. Без комментариев.
Про SoCи тоже больше говорить не будем. ОК!
Только о системе команд и какая из них лучшее и объясняя почему.

2. Они выбрасывают не 32-разрядный NIOS (ARM, MIPS, R....), а простенький 4-8 разрядный процессор.
Возможно это UNC80 (усовершенствованная архитектура МК 1878ВЕ1 з-да Ангстрем), они там карточками занимаются.
Возможно это что-то другое.

3. Просвещения ждут верующие, просветления - ждут буддисты, нормальные специалисты не ждут - они самообучаются.

Давайте ближе к теме уважаемые. А то выходные кончаются.

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

[zltigo]

Про SoCи тоже больше говорить не будем. ОК!

Отлично! Если просмотреть все Ваши "не будем говорить", то Вам остается молчать и это правильно! Поскольку ничем кроме псевдостистематизированного мусора изобилующего ошибками и высосанными из пальца Вами и цифирями Вы удивить не сможете . Смело вываливайте этот мусор заказчику (полагаю, что это отмывка денег где-то в районе зеленоградского ВПК ), но не надо его "обсуждать" - это уже чрезмерно.  

Я думал, что это только мне так показалось

Нет , там всякого полно в каждом абзаце. То тактовые частоты выбираются исходя их времени реакции на внешние события в миллисекунды, то цикл обращения к flash в контроллерах занимает до 20 нс. А как библиографический перл типа "Начала программирования" издания 1981 "использованом" для оценки трудоемкости программирования микроконтроллеров? "Анализ" тех-же PIC закончился на PIC17. 4bit контроолеры оказывается круто себя чувствуют в бытовой электронике и автомобилестроении. 8bit имеют наилучшие соотношения цены и производительности (тоже из какой-нибудь книжки издания где-то 1985 года) и с успехом используются для задач цифровой обработки сигналов. Студенту напишавшему такой труд твердый неуд. Что делать с Доцентом, даже не знаю  

[vitja]

...Вам остается молчать и это правильно!
...библиографический перл типа "Начала программирования" издания 1981 Ч
...то делать с Доцентом, даже не знаю

Просил без ?ля-ля-ля.
А сам не удержался, надеюся в последний раз.

1. Все чем мы пользуемся сейчас было заложено в 50-80-е годы.
Примеры ? Ваш и мой ?пень? вырос из 8086-го (1980 год), была даже его 8-разрядная версия (это ближе к теме).
- Крутой и наисовременнейший (2000 гг выпуска) МК MSP430 ? это клон PDP11, созданного в 70-х годах.
- Хорошие книги по программированию изданы в основном до 80-го года и сейчас только переиздаются (Кнут, Брукс младший и т.д. список большой, см. в библиотеке) .
2. Надо читать не только ДатаШиты и книги инструкции, которыми завалены полки книжных секций с литературой ?по так называемому программированию?
3. После 80-х годов программирование и аппаратура ЭВМ развиваются экстенсивно и эволюционно. В основном в сторону инструментария, который делают избранные.
Умные ребята от Гейтса превратили программистов в общество потребителей ? нажал нужную кнопку ? получил результат.
Мы ремесленники. Этим надо гордиться?
PS/ А книга называется "Начала науки о программах" Будьте внимательнее/ пожалуйста/

[MrYuran]

- Крутой и наисовременнейший (2000 гг выпуска) МК MSP430 ? это клон PDP11, созданного в 70-х годах.

Вот это действительно вещь. Вот его бы лучше проанализировали, а не допотопные пикушки.
И повторюсь ещё раз, говорить, что "система команд оптимальнее на 23%" без указания параметра оптимизации и критерия оценки, а также не имея конечной цели оптимизации - полный бред.

Тот же компилятор может оптимизировать по быстродействию либо по размеру кода. Параметры практически взаимоисключающие. При оптимизации по быстродействию приходится жертвовать размером и наоборот.

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

Вообще обычно при разработке нового типа МК производители берут готовое ядро (проверенное, широко известное и имеющее кучу инструментальных средств, т.к. компиляторы, симуляторы, etc)
А различия архитектуры наблюдаются на уровне функциональных блоков МК.
Например, мне сейчас в голову пришла мысль: а почему бы не сделать аппаратный шедуллер? Который по флагу моментально запускал бы нужное приложение, заодно соблюдая приоритет. Вот это была бы вещь, РТОСки бы летали. А курочить процессорное ядро без цели...

Тогда уж лучше трёхбитными процессорами заняться, вот уж где новизна! Вот где оптимальность! Не секрет, что оптимальное основание системы счисления - число е, которое намного ближе к 3, чем к 2

[vitja]

MSP430 это действительно вещь. Вот его бы лучше проанализировали, а не допотопные пикушки.

Тот же компилятор может оптимизировать по быстродействию либо по размеру кода.

Сделать что-то, оптимальное по всем параметрам, невозможно. Нужны критерии оценки и весовые коэффициенты ....

Тогда уж лучше трёхбитными процессорами заняться, вот уж где новизна! Вот где оптимальность! Не секрет, что оптимальное основание системы счисления - число е, которое намного ближе к 3, чем к 2

Полковнику не по порядку.
1. Критерии указаны - объем программного кода и числа тактов на его выполнение
при реализации операторов языка высокого уровня при доле (весе) их употребления
для задач не вычислительного характера (основная область применения МК).
2. Я тоже об этом - современный программист бац, нажимает кнопку, получил оптимальную
программу по объему кода, нажал другую, поднял быстродействие.
Зачем думать и говорить об эффективной системе команд? За нас таммм далеко в долине все это решили.
3. Современная элементная база мало пригодна для реализации логики с тремя состояниями.
4. Утверждение о том, что "вещщь" MSP430 это клон PDP11 (СМ3-4, Электроника 100, 1806 ВМ1 и прочие
аналоги) не опровергнуто/ а значит принято
5/ В ответ на пожелание привожу упрощенный анализ эффективности его системы команд по оценка объема кода
относительно 8051 (при обработке байтовых данных).
- длина команды - 16-разрядная переменной длины - 2.0
- адресность команды - 2-адресная регистровая - 0.73
- организация обработки - регистры, с возможностью задания констант и адресов
операндов в следующем слове. Тут сложнее, поскольку с одной стороны регистры, но не АВэРовские.
Поэтому пусть будет 1.0.
- организация выполнения команд - нельзя выполнить команду за такт,
и возможно даже за два (причина указана выше).
- состав команд - должно быть 1.0, однако поскольку константы имеют большой вес
среди операндов (условно примем 30%) на задание одного байта будет тратится
целое 16-разрядное слово, Поэтому 1.0 не получается, а получается где-то 1.15.
Итого имеем 2.0*0.73*1.0*1.15 = 1.7. Во столько раз с точностью достаточной
для практического применения МК430 уступает 8051.

Более точные оценки можно получить, если оценивать реализацию операторов ЯВУ в затратах
машинного кода М430.

[GetSmart]

5/ В ответ на пожелание привожу упрощенный анализ эффективности его системы команд по оценка объема кода
...
Итого имеем 2.0*0.73*1.0*1.15 = 1.7. Во столько раз с точностью достаточной
для практического применения МК430 уступает 8051.

Оценивать "эффективность" системы команд по отношению размера кода на "проделанную работу" не актуально. Флэши в современных процессорах очень много. Где-то 20..30 лет назад ситуация была другой и это имело смысл. Но не сейчас. Сейчас для всех более актуально измерять "проделанную работу" в секунду. Если по этому критерию оценивать MSP430 и MCS-51, то последний безнадёжно проиграет. Хотя с оговоркой. 430ые не делают на высокую частоту. Они специально заточены под минимальное энергопотребление. И по энергопотреблению он тоже "порвёт" 51ый.

Возьмём к примеру классический ARM7-TDMI. Он умеет работать в двух режимах. 32-битный код исполняется грубо в 1.5 раз быстрее Thumb-a, но имеет грубо в 1.5 раз больше объём кода. Вопрос на засыпку - какой режим эффективней?

б) максимальная частота выполнения программы ограничена временем доступа к ПЗУ/
в) за это время процессор сможет выполнить команду М430 за один машинный цикл/ затратив на это к примеру - четыре такта

А если за один доступ к ПЗУ считывать сразу две команды, то что? А если сразу 4?

Сообщение отредактировал GetSmart - Jan 19 2009, 10:50