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

[mikesm]

Позитивная критика. Во первых верный адрес файла http://moko.ru/mc/RatingMC.pdf
Во вторых, по моему, совершенно нет никакого смысла вот так глубоко анализировать затраты кода и производительности
на каждый МК. С практической точки зрения, критичными параметрами являются не доля затрат на некую команду,
а совершенно другие факторы: питание, тактовая частота, объем оперативной памяти, и число тактов на одну команду.
И уже существующие процессоры практически выбрали все варианты.
Т.е. типовой микроконтроллер работает при 3V на 8МГц. Мы берем сравнимые по цене процессоры.
И если он на 3.3V работает на 8МГц, выполняет пересылку регистр регистр за один такт, что еще от
него нужно?
Прирост производительности на 23% по сравнению с аналогами не сыграет никакой роли, потому что
идет массовый переход на C, а значит производительность программы будет зависеть от возможностей
компилятора. Который попросту завалит все преимущества.
Еще один ключевой момент, это наличие периферии, простота ее использования и эффективность
работы этой самой периферии. И тут мы уезжаем от теории регистр регистр к практической реализации
на уровне физики микросхемы. А вот эта тема практически Вами не раскрыта.
Если уж оптимизировать то по всем направлениям, система команд и организация памяти, как у Вас сделано,
плюс аппаратная реализация, чего не сделано, плюс эффективность компилятора, тоже не сделано.
Вот если все три направления задействовать, то возможно получится нечто хорошее, но тут вылезает
стоимость дизайна. Судя по тому, что в тексте процессор с 4КБ RAM и 16КБ Flash, этот вопрос Вы тоже
не рассматривали. Ведь в реальной продаже производители микроконтроллеров очень скупо дают
эту память. И при 16КБ Flash максимум на что можно рассчитывать это 256 или в крайнем случае 512
байт RAM. Значит она дорога в изготовлении. Еще есть вопрос энергопотребления в работе,
что тоже вопрос, к тому, для чего предназначен Ваш дизайн. Вообщем вопросов больше чем ответов.

[vitja]

...нет никакого смысла вот так глубоко анализировать затраты кода и производительности
на каждый МК. С практической точки зрения, критичными параметрами являются не доля затрат на некую команду,
а совершенно другие факторы: питание, тактовая частота, объем оперативной памяти, и число тактов на одну команду.

....производительность программы будет зависеть от возможностей
компилятора. Который попросту завалит все преимущества.

Первый ответ писался с работы из под UBUNTU, где не только знаки препинания найти невозможно, но и время и мысли.

По существу Вами поднято три вопроса:
1. Что считать критерием эффективности МК.
2. Влияние системы команд на аппаратные характеристики МК
3. Взаимосвязь компилятора и системы команд МК.

1. Критериев хорошести МК много.
Для схемотехника это конструктивное исполнение, напряжение питания, потребление, встроенные в МК интерфейсы
и специальные аппаратные блоки.
Для программиста это наличие инструментальных средств, достаточность ресурсов памяти и производительности для реализации алгоритма.
Для руководителя важно, что бы все было сделано быстро, дешево и сердито (конкурентноспособно).
Мое мнение, что во все этом большую роль играет система команд.

2. Система команд влияет на объем программного кода и время выполнения программы. Опосредственно это позволяет использовать модель МК с меньшим объемом ПЗУ, работать на более низкой частоте, со всеми вытекающими последствиями.
На сколько влияет - я попытался показать в своем анализе - в некоторых случаях многократно.

3. Несовершенство транслятора действительно существенно влияет на объем программного кода.
Однако это происходит не только из-за того, что их так пишут.
Просто система команд построена так, что под нее эффективный транслятор написать невозможно.
Это привело даже к тому, что появилось (в начале 80-х годов) новое направление - RISC ЭВМ, которые построены под трансляторы, а не наоборот.
Другое дело, что есть еще более приспособленные под трансляторы архитектуры - это стековые ЭВМ, но об этом рановато будет.