Архитектрура системы команд 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-архитектуру "расписываться" не стоит. Ее главная цель - обеспечить наилучшее соотношение производительность/цена процессора для определенного класса задач. "Удобство" для компилятора - далеко не главный фактор.

[vitja]

" RISC (англ. Reduced Instruction Set Computing) — вычисления с сокращённым набором команд.

"Удобство" для компилятора - далеко не главный фактор.

1. Не все, что написано на заборе, там можно найти.
2. Замечание я переадресую доктору Паттерсону в Беркли, который первым ввел слоган RISK, назвав им свои первые
риск машины RISK-I, II, которое прижилось в отличии от MIPS Станфордского у-ни и 801-го IBM.
3. Рекомендую читать первоисточники. В Wiku профессора не пишут, ее создает INET сообщество (толпа).
Ну вот, опять понесло. Прошу 3-й пункт не читать.

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

Я не фанат риска, но и не его противник. Я прагматик.

Поэтому давайте лучше решим, когда говорим о системе команд:

А) какой должна быть система команд, чтобы конвейер работал максимально быстро.

Б) нужно ли стремиться в архитектуре процессора МК к тому, что бы его команды выполнялись за один такт, поскольку выборка команд ограничена временем доступа к FLASH памяти программ (20 нс в известных мне фабриках и известных процессорах, исключая Scenix, где тактовая частота по ТУ 50 Мгц, но утверждается, что он может работать (непонятно за счет чего) на частотах 100-150 Мгц), когда процессор (его логика, регистры и память ОЗУ) может работать на частотах вдвое и даже вчетверо выше.

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

Г) когда мы говорим о повышении тактовой частоты, то надо говорить о возможности работы на этих частотах.
Так например, в системах реального времени процессор большую часть времени простаивает.
PS? Здесь я что-то невразумительное написал. Потом переформулирую. Пример оставлю. По п.п. а и б надо бы определиться.

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

[mikesm]

1. Не все, что написано на заборе, там можно найти.
2. Замечание я переадресую доктору Паттерсону в Беркли, который первым ввел слоган RISK, назвав им свои первые
риск машины RISK-I, II, которое прижилось в отличии от MIPS Станфордского у-ни и 801-го IBM.
3. Рекомендую читать первоисточники. В Wiku профессора не пишут, ее создает INET сообщество (толпа).
Ну вот, опять понесло. Прошу 3-й пункт не читать.

Вообще то, когда ты используешь термины, нужно быть более точным. Просто для того, чтобы можно было найти ссылки на информацию,
которую ты тут приводишь. Профессор Паттерсон, а точнее David Patterson, вот его домашняя страничка http://www.cs.berkeley.edu/~pattrsn
Имеет отношение не к машинам RISK-I и RISK-II, а к машинам RISC-I и RISC-II.
Что интересно, и первую и вторую машины разработали его студенты
RISC-I (1982) Contains 44,420 transistors, fabbed in 5 micron NMOS, with a die area of 77 mm2, ran at 1 MHz. This project coined the term Reduced Instruction Set Computer (RISC). This chip is probably the first VLSI RISC. Designed by Dan Fitzpatrick, John Foderaro, Jim Peek, Zvi Peshkess, and Korbin Van Dyke, students of Professors David Patterson and Carlo Sequin. The RISC CAD group included Dan Fitzpatrick, Professor John Ousterhout, and Howard Landman.
RISC-II (1983) contains 40,760 transistors, was fabbed in both 3 micron and 4 micron NMOS, and in 3 micron the size is 60 mm2, and it ran at 3 MHz. Designed by Bob Sherburne and Manolis Katevenis, students of Professors David Patterson and Carlo Sequin. (RISC group picture.)

А) какой должна быть система команд, чтобы конвейер работал максимально быстро.

Б) нужно ли стремиться в архитектуре процессора МК к тому, что бы его команды выполнялись за один такт, поскольку выборка команд ограничена временем доступа к FLASH памяти программ (20 нс в известных мне фабриках и известных процессорах, исключая Scenix, где тактовая частота по ТУ 50 Мгц, но утверждается, что он может работать (непонятно за счет чего) на частотах 100-150 Мгц), когда процессор (его логика, регистры и память ОЗУ) может работать на частотах вдвое и даже вчетверо выше.

Г) когда мы говорим о повышении тактовой частоты, то надо говорить о возможности работы на этих частотах.
Так например, в системах реального времени процессор большую часть времени простаивает.
PS? Здесь я что-то невразумительное написал. Потом переформулирую. Пример оставлю. По п.п. а и б надо бы определиться.

А) Большинство фирм выпускают микроконтроллеры с RISC архитектурой, где команды выполняются за один такт. Там нет огромной памяти,
поэтому не нужна частая многоступенчатая выборка.
Б) А иначе, при многотактном конвейере как быть с ветвлениями, анализировать код на несколько ходов вперед или использовать встроенную кэш память.
Это уже не микроконтроллер получится.

Г) Ничего он не простаивает, всегда можно выбрать частоту по вкусу, чтобы загрузка была оптимальной.

[vitja]

Профессор Паттерсон, а точнее David Patterson, вот его домашняя страничка http://www.cs.berkeley.edu/~pattrsn
Имеет отношение не к машинам RISK-I и RISK-II, а к машинам RISC-I и RISC-II.
Что интересно, и первую и вторую машины разработали его студенты


А) Большинство фирм выпускают микроконтроллеры с RISC архитектурой, где команды выполняются за один такт. Там нет огромной памяти,
поэтому не нужна частая многоступенчатая выборка.
Б) А иначе, при многотактном конвейере как быть с ветвлениями, анализировать код на несколько ходов вперед или использовать встроенную кэш память.
Это уже не микроконтроллер получится.

Г) Ничего он не простаивает, всегда можно выбрать частоту по вкусу, чтобы загрузка была оптимальной.

Робята, это не я сказал - "Первые машины RISC сделал David Patterson с его студентами (аспирантами)" (mikesm)
и я с ним абсолютно согласен.
Давайте не будем уподобляться рецензентам, которые говоря о недостатках отмечают отдельные стилистические неточности.
Будем зрить в корень. Русский язык велик и могуч, а русские ...

Поэтому о Рисках забыли.

По п.А. конкретно
Какая связь между размером памяти и глубиной конвейера?
Я ее вижу только в том, что память МК расположена всегдддда внутри кристалла, какая - от 32 байт, как в Tyni или до 64 Кб и более
не важно, главное не выходить за пределы кристалла для доступа к внешней памяти (иначе получается ПиСец с КЭШами в придачу, а не МК).

По п.Б
Читаем внимательно. Пишу медленно.
Я тоже самое говорил вышее, что и ты. Зачем эти лишние ступени в конвейере?
Выбрали Гарвардское расделение памяти на программы и данные, реализовали простенький 2-ступенчатый конвейер и никаких проблем.

По п.Г.
В системах РВ процессор простаивает по определению, поскольку он работает по событиям (прерываниям), которые он ждет, а значит простаивает.
Он это делает неспроста. Когда придет необходимость (событие), он должен все сделать, что бы уложиться в заданное время реакции на него,
а потом опять уснуть (до очередного события).
Менять частоту процессора на лету? Запомню, это программируемые PLL, но у них тоже есть какое то время выхода на устойчивый режим.
По п.Г я отклонился от главной темы "система коман МК". Больше не буду.

[mikesm]

По п.А. конкретно
Какая связь между размером памяти и глубиной конвейера?
Я ее вижу только в том, что память МК расположена всегдддда внутри кристалла, какая - от 32 байт, как в Tyni или до 64 Кб и более
не важно, главное не выходить за пределы кристалла для доступа к внешней памяти (иначе получается ПиСец с КЭШами в придачу, а не МК).

Даже если память расположена внутри кристалла, если мы говорим о 8 разрядном МК, то при адресации 64К требуется два байта адреса,
которые будут выбираться из Flash. И тут все зависит от аппаратной реализации процессора и его Flash на борту.
Если рассматривать стандартное исполнение, то Flash у процессора имеет побайтовый доступ, и если она больше 64К, потребуется больше
двух байт только на адрес, получаем выборку в 3 или 4 такта. А т.к. пересылка память регистр одна из наиболее критичных команд,
и в один такт выбрать команду не получится, надо делать конвейер. И чем больше размер памяти, тем глубже конвейер.