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

[Guest_@Ark_*]

"В течении 1980-84 гг в Беркли разрабатывался проект RISK, целью которого был выбор архитектуры однокристального СБИС-компьютера для эффективной работы с такими языками высокого уровня, как Си и Паскаль" из статьи RISC: "Эффективные архитектуры для СБИС-компютеров" Д.Патерссон и др. Электроника СБИС под ред.Айнспрука м.мир 1989
Поэтому в начале ты был прав, но концовка ....
Если рассматривать архитектуру RISC с точки зрения требований к системе команд процессора МК, а только это мы сейчас обсуждаем,
то оно одно - команды доступа к данным должны быть отделены от команд обработки данных.
Этому требованию в полной мере удовлетворяют регистровая система команд и стековая (если стек аппаратный).

" RISC (англ. Reduced Instruction Set Computing) — вычисления с сокращённым набором команд.
Это концепция проектирования процессоров, которая во главу ставит следующий принцип: более компактные и простые инструкции выполняются быстрее. Простая архитектура позволяет удешевить процессор, поднять тактовую частоту, а также распараллелить исполнение команд между несколькими блоками исполнения (т.н. суперскалярные архитектуры процессоров). Многие ранние RISC-процессоры даже не имели команд умножения и деления. Идея создания RISC процессоров пришла после того, как в 1970-х годах ученые из IBM обнаружили, что многие из функциональных особенностей традиционных ЦПУ игнорировались программистами. Отчасти это был побочный эффект сложности компиляторов. В то время компиляторы могли использовать лишь часть из набора команд процессора..."
http://ru.wikipedia.org/wiki/RISC

P.S. Возможно, какие-то из RISC-проектов были ориентированы по использование конкретных языков/компиляторов, но за всю RISC-архитектуру "расписываться" не стоит. Ее главная цель - обеспечить наилучшее соотношение производительность/цена процессора для определенного класса задач. "Удобство" для компилятора - далеко не главный фактор.