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

[vetal]

как не система команд

В первую очередь система команд это интерфейс ядра процессора с внешним миром. Взяли микроядро AVR без декодера и творите какую угодно систему команд.
Если бы вы поставили вопрос по другому: что лучше регистровый, стековый, регистровый с плавающим окном, аккумуляторный с одной или несколькими одновременно доступных памятей данных и т.д. то можно было бы судить. А так - все процессоры умеют складывать, вычитать, прыгать, загружать/выгружать данные куда-либо и создать систему команд под незнамо какую зверушку будет очень сложно.

[vitja]

1 В первую очередь система команд это интерфейс ядра процессора с внешним миром.
2 Взяли микроядро AVR без декодера и творите какую угодно систему команд.
3 Если бы вы поставили вопрос по другому: что лучше регистровый, стековый, регистровый с плавающим окном, аккумуляторный с одной или несколькими одновременно доступных памятей данных и т.д. то можно было бы судить. А так - все процессоры умеют складывать, вычитать, прыгать, загружать/выгружать данные куда-либо и
4 создать систему команд под незнамо какую зверушку будет очень сложно.

С Pashe не согласен/ Однако и Вы тоже/
1 Мне казалось/ что система команд это интерфейс программиста с процессором/ как я был не прав
2 см M8.zip в вывешенном каталоге/ на AVR это не похоже и на другие тоже
3 Именно я так ставлю вопрос и делаю попытку дать на него ответ/ не слушают
4 Создать систему команд для 8-разрядного МК/ сопрягаемого с транслятором/ удобного для программирования на ассемблере/
достаточно простого в аппаратной реализации

[_Pasha]

2 см M8.zip в вывешенном каталоге/ на AVR это не похоже и на другие тоже

Лично я бы заморочился на следующем:
1. Разбить ОЗУ на 256-байтовые банки, в которых живут все нужные регистры, т.е все регистры, в т.ч и РС и указатель стека - отображаемые на память. При этом оставить возможность байтовой адресации всего массива .
2. Оставить один неотображаемый регистр - селектор банка, в системе команд предусмотреть команду безусловного перехода с выбором банка памяти
3. Разрядность команд оставить фиксированной, но время выполнения все равно будет очень варьировать, особенно если пытаться навернуть 32 разрядную арифметику при 8 разрядной ШД. При всей абсурдности затеи с 32-разр арифметикой, получим выигрыш в компактности кода.

[vitja]

Лично я бы заморочился на следующем:
1. Разбить ОЗУ на 256-байтовые банки, в которых живут все нужные регистры, т.е все регистры, в т.ч и РС и указатель стека - отображаемые на память. При этом оставить возможность байтовой адресации всего массива .
2. Оставить один неотображаемый регистр - селектор банка, в системе команд предусмотреть команду безусловного перехода с выбором банка памяти
3. Разрядность команд оставить фиксированной, но время выполнения все равно будет очень варьировать, особенно если пытаться навернуть 32 разрядную арифметику при 8 разрядной ШД. При всей абсурдности затеи с 32-разр арифметикой, получим выигрыш в компактности кода.

Вчера весь день потерял на ненужные препирательства, достали.
Поэтому пропустил Ваши предложения.
По ним видно, что Вы единственный, кто ознакомился с M8.ZIP и
отметил непохожесть предлагаемой системы команд по сравнению с известными серийными 8-разрядными МК.
Из предложений остановлюсь, пока, на последнем.
Каждое принимаемое решение определяется ожидаемым результатом с учетом последствий принятого решения.
Я хотел добиться компактного кода – поэтому выбрал байтовую систему команд, 16-разрядная увеличивает объем кода по моим прикидкам в 1.22 раза (это один из результатов анализа rating.doc и писался он для целей оценки не конкретных моделей МК – заблуждение, а для оценки влияния архитектурных решений в системе команд МК и выбора наиболее оптимальных, а для этого нужны количественные, а не качественные оценки, пусть такие какие получились).
Далее, если выбрана байтовая система команд, то одноадресная как в 8051 Или другая.
Я выбрал стековую. Однако в нее ввел префиксную команду задания операнда, что позволило в рамках стековой архитектуры реализовать двух-адресные команды обработки данных (пересылка, унарные операции и модификация данных) и тем самым обеспечить сокращение числа команд до 0.73 по сравнению с 8051 (по моим прикидкам).
Выбор стековой архитектуры обусловлен еще и тем, что она хорошо сопрягается с трансляторами ЯВУ. Вспомним промежуточный P-код или Java байт-код, на который я ориентировался.
Переход на фиксированную длину 16-разрядов – это путь повторения AVR, его можно Чуть-чуть улучшить, но не радикально.
Форум не позволяет изъяснится подробно и доходчиво. Но, если есть понимание, то много слов не надо.
А 32-разрядность введена/ что бы посягнуть 8-разрядным ядром в область применения 32-разрядных МК/ а также иметь в системе команд возможность дальнейшего развития/
Пока. Об остальном подумаю.

[_Pasha]

Выбор стековой архитектуры обусловлен еще и тем, что она хорошо сопрягается с трансляторами ЯВУ. Вспомним промежуточный P-код или Java байт-код, на который я ориентировался.

Я бы сказал, эффективность работы трансляторов ЯВУ максимальна на архитектуре с небольшим количеством регистров, вернее, с небольшим объемом сохранения контекста процесса. А уж за счет чего это можно сделать - операций память-память, регистровых файлов -  это другой вопрос.

На примере того же АВР и Си видим, что до сих пор идет бурное развитие средств оптимизации, потому что эта регистровая модель немного не вписывается в сложившиеся технологии генерации кода.

Переход на фиксированную длину 16-разрядов – это путь повторения AVR

Имхо, проще и дешевле. Думается, что при введении команд (не псевдокоманд!), "каскадирующих" арифметику до 16/32 разрядов, может этот Ваш коэффициент 1,22  опять опустить ниже плинтуса Но это так - пальцем в небо.

И еще, можно АВР допилить до нужной кондиции так : разрешить операндам [Y+d] [Z+d] участвовать не только в операциях Load/Store. 

>>поток сознания иссяк

[vitja]

можно АВР допилить до нужной кондиции так : разрешить операндам [Y+d] [Z+d] участвовать не только в операциях Load/Store. 
>>поток сознания иссяк

Чищусь дальше (отвечаю на пропущенное)
1. В АВР нельзя. Они называют себя РИСКом, где по определению "команды обработки данных и комады загрузки/выгрузки регистров
разделены". Остальное - это конвейер и разделение шин доступа к командам и данным. Однако об этом лучше не писать мне, а прочитать.

Да не иссякнет поток сознания. Успехов

Moderator:
Поддерживаю.
To:vitja приведите свой "стиль" к человеческому. Считайте это устным замечанием. 

Сперва початимся.
"Все страннее и страннее" сказала Алиса. Я добавлю от себя - в обсуждении технических вопросов.
1. О русском языке
Транзакция - умное слово, означает обмен данными, включая чтение данных из памяти и запись данных в память ЭВМ
Бабло - деньги. Произошло из блатного жаргона, употребляют неформалы, маргиналы...
На конференции употреблено впервые 20.01.2009 в 22.00
Я это слово, только процитировал без указания автора. Вы еще Ж... пропустили у некоторых.
Поэтому какие замечания... Только к знакам пунктуации.
Да. Иногда приходится писать из под УБУНТУ, где все кнопки перепутаны.
2 Из жизни - Рецензент обязан написать - "есть отдельные стилистические неточности".

3. О человеческом языке - эсперанто я не знаю, поэтому говорю на русском (опять занесло - больше не буду)

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