Передо мной поставлена задача (сам напросился) - дать предложения по архитектуре
системы команд 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 и помогите "бедному" разработчику, кто чем может по делу,
без ля-ля-ля, смайликов и спама, - советом, предложением, позитивной критикой и замечаниями. Не дайте загинуть концепту.

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

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

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

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

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

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

Система команд какого ядра с вашей точки зрения более эффективна: 80с31(частота 12МГц, время машинного цикла 12 тактов, время исполнения команды 1-n машинных циклов) или x51(частота 12Мгц, время исполнения любой команды - 1 такт)?

Из вашей оценки

Площадь 51 контроллера примерно равна площади ARM Cortex-M1, NIOSII. При том, что равный по площади 51 микроконтроллер будет работать на меньшей частоте за счет того, что у него очень тяжелая система команд.

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

А Вы уверены, что это так? По моему, причины появления RISC-архитектуры были совсем другие. В первую очередь - необходимость максимального удешевления процессора. Отсюда - сокращенная (RISC) система команд, состоящая из минимально необходимого набора. А сами команды - максимально просты для достижения максимальной скорости выполнения. То есть - максимальная производительность при минимальной стоимости. IMHO, трансляторы здесь не причем.

1 Тактовую частоту байтовой системы команд переменной длины 8051 я оценивал не по оригиналу,
а по потенциальной возможности выполнения этой системы команд - байт за такт, плюс холостой такт на запись результата в командах модификации
даннах в памяти и смене счетчика команд в передачах управления.
Где близко к этому работают последние модели 51-х от ATMEL. Хотя мне кажется, что ядро процессора у них работает на удвоенной частоте,
только кажется.
Что бы предупредить такие вопросы по PIC, то в нем для расчетов числа тактов принято 2 такта на команду, по причине того,
что он обрабатывает данные в памяти (так называемом регистровом файле достаточно большого размера).

2 Спасибо за данные..++
Я предпологал, что это так, но не думал, что до такой степени.
Обязательно учту и проведу перерасчет оценок площади.
Если знаешь аналогичные отношения для процессора AVR MEGA и PIC не ниже 16-го, подскажи.

1 Благодарен за прочтение и правильные выводы:
а) я действительно анализирую эффективность только процессора МК, причем только его системы команд;
б) задачей этого анализа является оценка влияния особенностей системы команд на объем программного кода и тактов на его выполнения.
Для оценки были взяты статистические данные употребления операторов ЯВУ для нечисловых задач, как наиболее характерных для областей применения МК, где объем вычислений относительно невысок.
Когда я рассматривал другие показатели эффективности МК - площадь (стоимость кристалла), трудоемкость программирования на ассемблере и еще бы надо не забыть о потреблении, как функции тактовой частоты, то все это было упомянуто только в качестве примеров влияния системы команд на эти показатели.
Для всех!!!
Я думаю, что вопросы эффективности МК в целом достойны обсуждения ,но в другой теме. Договорились.

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

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

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

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

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

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

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

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

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

Вообще то, когда ты используешь термины, нужно быть более точным. Просто для того, чтобы можно было найти ссылки на информацию,
которую ты тут приводишь. Профессор Паттерсон, а точнее 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.)




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

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

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

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

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

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

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

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

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

----------------------------------


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

1 Поскольку мы о RISC-философии больше писать (говорить) не будем,
позволю себе, в последний раз нарушить это соглашение и привести полное название первоисточника "RISK:Эффективные архитектуры
СБИС-компьютеров", остальное в его тексте, в т.ч. о целях разработки (см.вышее, и еще вышее)
Надо знать и уважать авторов.

2 Я тоже, как и вы, когда принимаю какое-то решение, сомневаюсь и что-то оставляю на потом (держу в уме).

Организовать вычислительный процесс в СРВ можно по разному. Я сказал об управлении по событиям (прерываниям), вы - об управлениии по
цикло-чего то (забыл как называется) - это разделение времени.
Какое отношение организация ВП СРВ имеет к системе команд, где надо:
а) отреагировать на прерывание;
б) при необходимости сохранить контекст текущей задачи, и позжее его восстановить.
Это реализуется командами PUSH,POP и RETI. Возможны другие варианты не изменяющие смысла.
Еще 3 команды в копилку системы команд процессора МК.

Давайте ближе к теме будем быть.


Слава богу. Наконец то мы стали говорить по теме.
Да - память ПЗУ, ОЗУ внутри кристалла МК, да - это 8-разрядный МК и адресация 64к требует 16 бит адреса как ПЗУ, так и ОЗУ,
а более 64 к - более 16 бит.
Ее можно адресовать странично или относительно базового адреса. Это не требует задания в команде всех битов адреса, можно ограничится 3,4 или другим числом биттттттттттттттофффффффф.

Сегодня все. Хочу спать.

Я стою на форуме с протянутой рукой уже второй день.

Подают фантики. Спасибо mikesm и vetal за позитивную критику и уточнение. Не дали умереть с голоду вчера.
Но сегодня мне снились процессоры с CISьСами и RISьCами и программист.

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

Вторые имели фиксированную длину команды, обрабатывали данные на регистрах за один такт, сопрягались с трансл

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

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

 

RISC - отстой Грядёт эпоха сверхдлинных CISC по подобию Эльбруса E2K.
Зачем спрашивается процессору в рилтайме анализировать возможность выполнения нескольких инструкций за такт, если компилятор один раз сам может это сделать и сформировать инструкцию, исполняющуюся за 1 такт и производящую множество разных действий?!

Да чё уж там, сразу надо JAVA-процессор делать, чтоб прямо исходники глотал. Слыхал, что уже есть такие.

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

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

Доцент



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

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

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

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

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

 

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

Ну все верно, Вы говорите, что рынок занимают, что место не уступят. Вот только смысл этой эффективности теряется среди других вещей.
Вы пишете, давайте обсуждать эффективность ядра процессора. Смысл обсуждать эффективность ядра, если другие компоненты микропроцессора
завалят эту эффективность в два счета. Как к примеру обсуждать эффективность применения аспирина утром или вечером, что эффективнее, принять
его в 9.15 утра, или 17.15 вечера, и все это в приложении к алкашу. Нет смысла, для его здоровья гораздо эффективнее бросить пить.
Также и здесь умозрительная задача, обсуждать ради обсуждения, без какого нибудь практического выхода в обозримом будущем.
Какой смысл обсуждать эффективность структуры команд, если повышение тактовой с 8 МГц до 16МГц, на любой платформе дает прирост в 200%,
против эффективности структуры команд, которая в предельном случае даст прирост 23%.
Поэтому с практической точки зрения, обоснуйте, хотя бы теоретически, какой выигрыш даст Ваша тема, хотя бы виртуально, чего не достичь
другими методами, там повышением частоты, переходом на другую технологию чипов или еще как то. Тогда хоть будет интересно обсуждать.

Данные фирмы Atmel :
http://www.atmel.com/dyn/resources/prod_do...nts/doc3323.pdf


Я думаю так - длина команды д.б. в районе 11-12 бит. Туда вы сможете запихать наиболее востребованные операции. Для выполнения длинных переходов добавить несколько команд из 2х слов. Больше ничего не сказать, т.к. это будет зависеть от выбранной вами архитектуры(микроархитектуры)!

"Обсуждать эффективность структуры команд" стоит хотя бы по по трем причинам ... о чем я говорил ранее давно и не буду повторяться.

А вот вера в прогресс техники - удвоить тактовую частоту или перейти на технологию 0ю13 мк - это другое.
Почему. Удвоение частоты приведет к удвоению потребления. Переход с 0.18 мк на 0.13 занял много лет и еще больше денег, хорошо что не наших.
Так или нет.
Я утверждаю в http://moko.ru/mc/ (таблица) 32, что система команд оказывает существенное влияние на эффективность МК (в попугаях).
И эта эффективность отличается не на 23%, а в два и даже три раза.


1. Первый абзац это самое правильное, что я здесь видел.
Пример для всех.
Будьте кратки, при возможности давайте ссылки на первоисточник.

Ответ.
Из указанного материала я понял, что кроме двух известных древних проффессий, есть третья - аналитики (прогнозисты).
Из ссылки - "аналитическая компания Semico в 200ю году предсказала для фирмы Atmel, что к 2007(8) году
32-разрядные МК будут преобладать на рынке"

Из PC Week от 5 декабря 2008
доля рынка МК
"14% 8051
12% PIC
3% AVR
1% ARM . Остальные места занимают другие фирмы со своими проприентарными процессорами (Motorola, Zilog, Holtek, Sani...)
По прогнозу аналитической компании Semico к 2010 году дC

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



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


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

 

Даже если это так (хотя я сильно сомневаюсь), то большая доля 8-битных контроллеров обусловлена привязанностью к уже написанному ПО. Из этого совершенно не следует, что будет востребована новая архитектура 8-битных контроллеров. 8-битники - прошлый век. Давайте ещё АВМ реанимируем
Я просмотрел PDF не очень подробно и заметил только совершенно непонятные (неадекватные) цифры в таблицах. Особенно удивила таблица со стоимостью МК (архитектуры). Сравнивите к примеру AVR и ARM со флэшем хотя бы 64К и удивитесь сколько необъективности в вашем PDF. Буквально по каждой таблице можно долго спорить, но не буду. Жалко своё время.

Кроме этого, есть много способов поднятия быстродействия микроконтроллера. Те же AVR при желании Atmel-a можно было бы ускорить в 4-6 раз не переделывая систему команд. Но почему-то это не делается. Может для 8-битников такая скорость и не требуется.

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

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

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

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

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

2vitja:
Создайте симулятор системы команд и оцените на нем все перечисленные вами тезисы. Для чистоты эксперимента любая команда должна будет исполняться за 1 такт - это даст возможность исключить нюансы реализации.
Если вам так хочется сравнить 8 и 32 бита - сравните стоимость вычисления постоянной составляющей синусоиды(кол-во отсчетов 32, кол-во элементов - 32, разрядность данных -16) , FIR 32 порядка, поиск числа в массиве, поиск подстроки в массиве строк и како-го нибудь алгоритма шифрования. После реализации этого всего можно будет сделать вывод о том, какие инструкции наиболее употребимы на типовых задачах микроконтроллера и их вес.

PS: http://mcu.caxapa.ru/benchmarks/

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


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

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

Уже поздно.
Из всего отмеченного только по п.2 (по другим завтра)

2. Спасибо, что прочитали. На цифры не обращайте внимания. Статистика может обосновать все,
есть законы о нормальном распределении, есть выводы теории погрешностей ....
Поэтому цифры можно перепроверять и пересчитывать, но зачем. Важны полученные оценки.
Объем кода (табл.32) при обработке данных 8-32 разряда:
AVR 8051 ARM M8
3.3 2.4 2.0 1.0

И еще личная просьба.
Не пожалейте еще немного своего времени, раз уж посмотрели PDF.
Скажите про Ваше отношение к цифрам в таблице 19 (глава 4), где приведены доли типовых машинных операций
на реализацию операторов ЯВУ.

Всем спокойной ночи.

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

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

Да! Имено так, вот и лично Вы занялисть очередным переливанием из пустого в порожнее изображая пустейшее наукообразие в рассуждениях уровня экономии кремния при создании каменных топоров. Что новенького-то??? При этом лично Вам ни каменный топор, ни восьмибитовое ядро не нужно. В результате одно пустое цитирование некомпетентного и незаинтересованного человека. Что-то не слишком далеко ушедшеее от репортажа-обзора в каком-нибудь глянцевом мужском журнале сделанным журналистом по заданию редакции.  

 

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

При чем тут это? ВЫ утверждаете, что вам нужна помощь в системе команд и тут же делаете ссылку на архитектуру процессора. Вы уж определитесь чего вы оцениваете!!! Вам уже 100 раз говорили, что система команд сама по себе не появляется нужна архитектура.

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

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

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

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

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

Да, кстати, про 2000 год и MSP430 опять ерунда наверное почерпнутая из журнала "Плейбой" - MSP430 лично я держал в руках с горой документации в 1996 году и сравнение c PDP за уши притянуто с не меньшим успехом можно утверждать, что это Intel. Вообще, я уже говорил, весь "анализ" реальных ядер явно строится на бумажных русскоязычных изданиях 80x-начала 90x. Вот и получается, что PIC типа умерли на PIC17. ARM - на АRM7, Atmel еще не пытается делать XMEga, MSP еще не родился, про 80251 тоже в советских книжках не написали, 32bit мы вообще не рассматриваем потому, что в тех книжках писали, что они неоптимальные, ядра для SoC вообще вообще, наверно марсиане проектируют.

 

Полковнику не по порядку.
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.

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

Я читал/ признаюсь/ ДатаШит М430 по диагонали/ однако систему команд 1806 ВМ2 знаю и уважаю /опять признался/
Однако ничего личного/
В ней за такт можно выполнить только обработку данных на регистрах/
Остальные же в/т/ч/ способы адресации только добавляют такты в выполнение команды/
Переходы действительно сбивают конвейер/ Поэтому придумывают типа предсказания переходов и прочие навороты/
Зачем/
а) В МК вся память внутри/
б) максимальная частота выполнения программы ограничена временем доступа к ПЗУ/
в) за это время процессор сможет выполнить команду М430 за один машинный цикл/ затратив на это к примеру - четыре такта

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

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


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

Что такое архитектура процессора МК//
как не система команд /см/книгу "Организация ЭВМ" издание 5-е 2004 год Питер/
Однако если на нее посмотреть с другой стороны/ то она может выглядеть как 18-ноговый DIP корпус
первые пентиумы потом я носил как значок/ прикольно было

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

1/ на первые два вопроса вы ответили сами - а) не делают потому/ что у них система команд такая - переменной длины да еще с возможностью
обработки данных в памяти/ что в принципе не позволяет реализовать однотактный конвейер/
б) 32-битный код исполняется в 1.5 раз быстрее Thumb-a (критерий число тактов),
имеет в 1.5 раз больше объём кода (критерий затраты программного кода).
Насчет одновременной выборки я подумаю/
Действительно/ если процессор может работать на частоте более высокой
чем выборка команд из ПЗУ то и пусть работает
Однако как быть с потреблением/ Оно тоже вырастет
В сигнальниках и VLIM архитектурах действительно одновременно выбирается несколько команд /
однако они /при возможности/ выполняются за один такт /за счет параллельной работы независимых обрабатывающих блоков
Мне кажется это более правильное решение/ а не такое лобовое/ как то что вы предложили

Гы Я предложил то, что уже реализовано в LPC2xxx (ARM7). "Лобовое" иногда самое эффективное. Тем более если ядро может работать на частоте в 5-10 раз большей чем флэш/ПЗУ.

Лучше некуда. 

Только дополнение по поводу клонирования
См.формат двух-адресной команды
BKKK mmmRRR mmmRRR (PDP11) и KKKK RRRRmB mmRRRR (MSP430)
В-байт или слово, R-регистр источник и приемник, m-мода адресации.
При непосредственной адресации следующее слово команды содержит константу, при косвенной-адрес.
В чем принципиальные отличия. В числе регистров? 8 и 16. В их использовании - в PDP11 PC и SP это R7,R6, а в MSP430 - R0,R1.
Вобщем содрали архитектуру, надеюсь не испортили, навесили рюшки, фишки и назвали все это RISCом, иначе не модно
И сделали это 26 лет после DEC (в 1996 году)

Без ля-ля не получится потому что вы несете полную ахинею, причем ахинея в самой постановке вопроса.

Вопросы выбора процессорной архитектуры были закрыты в XX веке. Ничего концептуально нового в области традиционных процессоров уже не придумать, поэтому мы и пользуемся разработками 80-х или 90-х.
Важность инструментария в связи с этим стала превышать важность архитектуры. Плохой компилятор ЯВУ угробит любую процессорную архитектуру, а хороший вытянет даже убогий процессор. Трудоемкость разработки компилятора генерирующего высокооптимизированный код на порядки превышает трудоемкость разработки процессорной архитектуры. Для нового самопального процессорного ядра компилятора у вас либо не будет либо он будет неэффективным. Отсутствие или плохое качество компилятора - смерть для процессорной архитектуры.
Именно поэтому разработка новой архитектуры процессора сейчас либо самоубийство либо чистый попил бабла.

Да, с конца 80-х микроконтроллеры стали ремеслом, сейчас и компьютерщики тоже становятся ремесленниками.

Ваши утверждения о том что MSP430 клон PDP11 смехотворны. PDP11 имеет ортогональную систему команд, а MSP430 - не ортогональную. Отличие концептуальное! MSP430 создан "по мотивам", но он отнюдь не клон.