vitja, на этом форуме сложились некоторые правила, которые следовало почитать, прежде чем оставлять сообщения.
Помимо прочих, обсуждение действий модератора наказывается запретом оставлять сообщения на форуме на неделю.
Настоятельно рекомендую воспользоваться этим временем для раздумий о своём поведении.

vitja, ваш процессор кое в чем похож на M16C/R8C от ренесас, в них стек ( 3 pointer'a ) можно использовать как регистры, достоинство при входе/выходе из подпрограм: вместо множества push-pop команд переадресуется указатель стека.
советовал бы и переименовать свои проект а так многим оно ассотсируется с мк M8 Cypress'a.

По вашей рекомендации посмотрел М16С от Ренесас. Спасибо.
На 300-странице Шита батарейки у бука кончились (шнур питания отскочил).
Однако общее впечатление сложилось.
За что уважаю японцев – за то, что любую чужую идею могут довести до совершенства, из автомобиля Форда сделать Ниссан, из транзистора – Панасоник, из интегральной схемы – Сони.
Так и здесь. РОН ДЕС, превращены в 8 специализированных регистров – Р0-3,А1-2, РБ и SP. Стековые фреймы взяты из х86, байтовые команд, наверное, из 8051, даже ввели 4 разрядную ИММ в команду и многое чего друго ……
Однако главное сделали добротный практичный продукт, не заморочились на РИСК с его конвейером, используют многотактные команды переменной длины с прямой обработкой данных в памяти и не только 16-разрядные, но и байтовые.
Жаль, что мы не знаем японского, а то бы ответили, но тогда не было бы М16...
Но как сказал, мой знакомый индивидуальный предприниматель "даже на пончиках можно прилично заработать, просто их надо делать"...
Вот и я того же мнения и Мицубиси одобряю, и сампопытаюсь что то сделать несмотря ....

в какое количество логики подобие M16C выльется? получится ли это ядро простым? на какой частоте оно заведётся?

кстати, в отличие от ваших виртуальных выкладок TI уже который раз подряд что-то сделал на основе практических исследований: http://focus.ti.com/lit/an/slaa205c/slaa205c.pdf
конечно, тут немного притянуто за уши. но в целом картина более-менее правдивая. в отличие от.

Благодарю за ссылку. И даже посчитал для М8 бенч 8 на 16 CASE. получил 135 байт без оптимизации (MSP430 198, arm7 - 338, pic18 - 208, atmega 350 с оптимизацией). Еще раз спасибо Вам и TI...

Ну и что? У меня 36-разрядная архитектура(для FPGA выгодно брать разрядность из ряда 9/18/36 - память полнее используется) - для нее неоптимизированный switch_case выливается в (автокод):

- что дает ~300 байт и ~40 тактов(неймановская архитектура, регистровый файл на памяти - вместе с кодом). Но те-же цифры будут и для 16-разрядных данных, и для 32-разрядных. Так что не вижу смысла даже в 16-разрядных ядрах, не то что в 8-разрядных.

а вы, однако, оригинал. для вашего М8 уже есть компилятор от IAR? методика расчёта совпадает? или вы вырезали свои 135 байт из контекста Си-кода?
сравнивать нужно подобное с подобным. попробуйте написать код аналогичный вашему для М8, для остальный приведённых процов, ручками. тогда и сравнивайте.

"ничто так не улучшает результатов, как новая "улучшенная" методика измерений"

; Name : 8-bit 2-dim Matrix
; Purpose : Benchmark copying 8-bit values.
;typedef unsigned char UInt8;
;const UInt8 m1[16][4] = {
;void main (void)
;int i, j;
;volatile UInt8 m2[16][4], m3[16][4];
call uint8
.byte {0x12, 0x56, 0x90, 0x34}
…
.byte {0x90, 0x34, 0x78, 0x12}
Ret
;};
_for ldl 16 st I ;for(i = 0; i < 16; i++)
_for ldlA m2 \ ldlB m3 ;for(j=0; j < 4; j++)
_do R+ ldd std(IA) ; m2[i][j] = m1[i][j];
@+ ldd(IA) @+ std(IB) ;m3[i][j] = m2[i][j];
_next I dec <cc>
_endo
Ret ;return;
Результаты ТИ MSP-86 ARM-393 8051-398 PIC-324 ATMega-354.
Для М8 получилась исчезающе малая величина - 21 байт.
Продолжаю знакомиться с материалами ТИ. Благодарю ВАС за возможность увлекательного чтения. Особенно меня восхитило одно из примечаний к PICу «did not support the memory model required for Whetstone analysis».
Следующим планирую посчитать КИХ фильтр, но оптимизированный на базе фиксированной, не плавающей арифметики.


Код М8 на базе вашего автокода......
proc switch_case ;(a)
dup ; var output
_if eql 1;a = 1
_then drop \ ldl 1 \ ret; output = 1
; ...
_if eql 16;a = 16
_then drop \ ldl 16 \ ret; output = 16
_endi

//-----------------------
proc main
; var result
ldl 10h call switch_case; result = switch_case(16) на верхушке стека
ret; return
//-----------------------[/code]
- что дает 135 байт, а не 300. Почти те-же цифры будут и для 16-разрядных данных, и для 32-разрядных. "Так что не вижу смысла даже в 16-разрядных ядрах, не то что в 32-разрядных".

Включая таблицу?


Полагаю, так-же аккуратно подсчитано, как и для "21 байт"

Да. Байты таблицы следуют сразу за вызовом процедуры (их расположение ТИ не оговорила).
При вызове процедуры адрес возврата записывается в стек. Используя байтовую команду команду R+ldd четверка очередных байт таблицы считывается и .... Выход из процедуры осуществляется по модифицированному адресу возврата.
********
Это последнее
;* Purpose : Benchmark an FIR filter. The input values for the filter
;* is an array of 51 16-bit values. The order of the filter is * 17.
;const float COEFF[FIR_LENGTH] =
;{ -0.000091552734, 0.000305175781, 0.004608154297, 0.003356933594,
........0.000305175781, -0.000091552734};

Coeff: .word ….
;/* The following array simulates input A/D converted values */
;const unsigned int INPUT[] =
;{ 0x0000, … 0x0000, 0x0000,;....... 0x0C00, 0x0800, 0x0400};
Input=1000h
;void main(void)
;int i, y; /* Loop counters */
;volatile float OUTPUT[36],sum;
Output=1100h
mainM8:
_for ldl 36 st y LdB output ;;;;;;for(y = 0; y < 36; y++)
_do lddl 0 ctd sum ;;;;sum=0;
_for ldl 8 st i ;;;;;;for(i = 0; i < FIR_LENGTH/2; i++)
Ldwl coeff SpushR
ldwl input ldl 0 ld y adw drop pushB adwl 16 pushA
;;;;sum = sum+COEFF[i] * ( INPUT[y + 16 - i] + INPUT[y + i] );
_do @- ldwA @+ ldwB adw ldwR+ imulw add
_next I dec <сс>
_endo
;;;OUTPUT[y] = sum + (INPUT[y + FIR_LENGTH/2] * COEFF[FIR_LENGTH/2] );
ldwl input+8 ldl 0 ld y adw stwB ldwB ldwR+ imulw ldd Sum add
ldwl output ldl 0 ld y adw pushB stdB
_next y dec <cс>
_endo dropR ret ;;;;;return;

В МК FLOAT использую либо от лености, либо по незнанию вычислений с фиксированной точкой. Поэтому считаем, что не смтря на их 5-разрядный АЦП мы получаем 16-разрядные коды. Что бы сохранить погрешность на уровне младшего разряда, коэффициенты также принимаем 16-битными, МАК считаем 32-разрядным для предупреждения накопления ошибки вычислений.
Результаты TI MSP430 – 986;ARM thumb – 1528;8051 – 2056;PIC18 – 2006;Atmega8 – 1356.
M8 69(+-) байт кода (без таблицы коэффициентов, иначе + 34 байта) с точностью достаточной для практического применения 8-разрядного МК для решения задач ЦОС, например, звука. Из байт большая и самая запутанная часть ушла на вычисления адресов, а не самого фильтра.

Вывод. Надо срочно менять в системе команд механизмы доступа к данным. Надо отказываться от индесных регистров (содранных с АВР) и вводить другую. Может быть базовую, как в Ренесанс, может быть ... вариантов много. Какой выбрать?

Таблица - это 64 байта, которые надо прибавить к "21 байт". Как и все вспомогательные константы, коды инициализации и проч - для получения полного рабочего кода, который можно загрузить в процессор и выполнить.

Вариант для М8 не является аналогом Си-варианта от TI, а эквивалентен следующему:

Это уже оптимизация, тк исключается команда перехода.
Так-что до корректного сравнения ой как далеко.

Со всем согласен.
Второе это результат ручной оптимизации, которую, наверное, автоматически проделали в ТИ, поскольку я приводил их оптимизированные данные (без оптимизации они хуже). Действительно, зачем писать команду перехода в конец выбора, что бы там выполнить РЕТ.

Перовое ое результат моей спешки. 64+21=85 по сравнению с 354 байтами АВР это не «исчезающее малая величина» - это просто величина меньшая в 4 раза. Из этого не следует вывод, что система команд М8 в 4 раза эффективнее, чем у АВР.

Это потому, что и в этом тесте код для М8 не является аналогом Си-варианта от TI, а эквивалентен, скорее, следующему:

Лучше другие тесты брать, где нет явной оптимизации, а эти "от TI"(на сахаре те-же) - в помойку.

Я влез в бенчи, поскольку мне здесь настоятельно посоветовали не пользоваться доморощенным рейтингом, а взять бенчмарки и на них оценить эффективность системы команд М8. Я это сделал за выходные, используя исходники тестов фирмы TI для MSP430, и получил результаты. Оказалось, что эффективность М8 по тестам ТИ превышает эффективность АТMega во много раза, когда по моим рейтингам всего лишь в 1.6 раза (3 раза получилось только для 32-разрядных данных). Кстати, тоже самое, в смысле его эффективности, получили разработчики MSP430 относительно других МК.
****Вывод. Нельзя верить заказным бенчам, нельзя верить мне, нельзя верить фирме TI и прочим – надо верить самому себе, здравому смыслу, своему опыту, академикам и интуиции.
*** Ты прав в твоем (моем) примере я «оптимизировался», избавился от внутреннего цикла последовательной пересылки 4 байтов, за счет пересылки сразу 4-байтного (32-разрядного) слова во внешнем цикле. Это был рефлекс программиста, не устоял от соблазна.
***PS. Мне дали ссылку на Сахару и на Ти/// согласен/// в помойку их///
****Не мог бы кто нибудь предложить тройку (пятерку….) тестов, ****действительно характерных**** для областей применения 8-разрядных МК с исходниками на Си и рейтингами других 8-разрядных МК по объему кода, желательно без оптимизации, плавающей арифметики и не очень больших, поскольку транслирую вручную (я не разобрался в Сахаре и могу из нее выбрать «удобные» для М8 тесты). Заранее признателен.
****PS2. Прочитал в первом номере «Современная электроника» о нашем отечественном микроконтроллере 1886 ВЕ фирмы Миландр.
Ведь могут найти деньги и сделать с достаточно хорошими характеристиками.
Однако это клон PICа… В рейтинге TI он стоит на последнем месте (Меня позабавило данное ими примечание к PICу «did not support the memory model required for Whetstone analysis»…. Почему не cделать М8 за теже деньги, но с большей эффективностью, где Whetstone analysis поддерживается?? Я не понимаю. А вы?
***** Написание тестов выявило существенные недостатки архитектуры М8 по организации доступа к данным. Поэтому я задумался об этом. Продуманное выложу чуть позже.
******* Но не дают гены покоя*********************************
К вопросу о совместимости системы команд и ЯВУ (один из показателей эффективности МК)
Остальное я упоминал – первое это минимальный объем кода, остальное - эффективная реализация в аппаратуре (в тактах, площади, потреблении…), а также концептуальность системы команд, ее ортогональность и возможность расширения (развития).
**Итак о совместимости с ЯВУ***Почитал описание языково-ориентированного (под Си, Паскаль, Модула…) процессора КРОНОС, разработанного и сделанного в конце 80-х в Новосибирске, опередившего Интел с их Пнем на много лет. Так вот, академики из Новосибирского филиала РАН выбрали для его машинной реализации 0-адресную систему команд, как наиболее эффективную…. Кто прав – академики из РАН или те, кто предлагает «морэ регистров» для обеспечения совместимости с ЯВУ вместо стековой архитектуры? Вопрос для меня не из простых?

Потому-что для пика есть средства разработки, а M8 только на бумаге. Когда M8 будет обеспечен типовыми средствами разработки(как миниму C - компилятор, отладчик(симулятор), внутрисистемный отладчик) тогда и можно будет на что-то претендовать, а в вашем случае это пока просто набор вентилей(и тот на бумаге).

Москва тоже не сразу строилась// Надо же с чего то начинать // сперва проект на бумаге потом в железе и параллельно средства разработки//

Вы явно недооцениваете данный этап

как вот такая вот абракадабра

согласуется с


ну и где тут удобство программирования на ассемблере?


тесты TI все собирались компилятором IAR. для всех платформ. и тут выскакиваете вы, пишете некую абракадабру, которую никто проверить не в состоянии. и заявляете, что по результатам особо тонкой ручной оптимизации вы тут всех уделали. а как это проверить? для доброй половины самопальных ядер есть хотя бы транслятор ассемблера.


все эти звёздочки и чёрточки вместо знаков препинания русского языка заставляют усомниться в адекватности человека, так свирепо их использующего.


для того что бы оценивать хоть что-то (хоть объём кода, хоть такты и площадь) необходимо иметь минимум модель проектируемого устройства. а то что-то мне кажется, что противоречий при реализации в железе вашего ужаса М8 будет море.

"У людей не хватает времени что-либо узнавать/ Они покупают вещи готовыми в магазинах"/ где ///
Так сказал Лис/// "Антуан/ёёёёё////
За ссылку на тесты спасибо/ Однако нельзя ли ближе к 8-разрядным МК? без флоат и транспортирования матриц/
Дайте честные тесты характерные для 8-разрядных МК/ без оптимизации как в ТИ//
Три или 5 тестов с исходниками на Си и оценками затрат программного кода для известных 8-разрядных МК (без Сахары)/
Буду благодарен///
За абракадабру извините/ Не придумал еще символики понятной для /// и интуитивной для умных/



Я даже очень оцениваю////Но нельзя ставить телегу впереди лошади как Вы предлагаете//
Нет системы команд/// нет прочего ////Включитесь в предыдущий этап - поучаствуйте в создании систему команд
для 8-разрядного МК (стекового)/ Предложите//// Однако Спасибо

Мoderator:

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

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

нет отдельно тестов для 8-разрядных МК и отдельно для 16-разрядных. как нет тетрадей для 5-го класса. и зачем вам три или пять тестов? возьмите один. но всеобъемлющий. для начала сойдёт и Dhrystone. он опять же есть в доке от TI. тест этот придуман не TI, и используется уже много лет для абсолютно разных архитектур. тест далеко не совершенен, но это самое доступное из того, что можно придумать. тем более что уже есть куча результатов этого теста.

поучаствовать? а смысл? представим что это ядро уже есть в виде исходников. и пока нет реализации в кремнии - используем их в качестве soft-ядра в FPGA. и что мы видим? компилятора под этот кошмар ждать лет 10-15. писать на ассемблере? опять нет смысла. ибо сэкономленное на размере памяти отыграется в размере самого ядра. я уже вижу, что ядро обойдёт по размеру MicroBlaze, при том, что частота работы будет много ниже. так зачем тратить силы на заведомо провальный проект?

Тема очень забавная Не хотелось бы чтобы её закрыли. В качестве наказания лучше банить автора на день. Тогда он быстрее найдёт все знаки препинания на своей убунте.

А настойчивость автора похвальна

Спасибо. (Нашел знаки препинания на чужой убунте).
Но нету темы!!!. Есть только знаки препинания от некоторых...За них меня банить....
Предлагаю ........




*****Эпилог
Получили разнообразные способы доступа к данным (в т.ч. в стеках и ПЗУ) , а также форматы команд (от 0 адресных до 1 и 2 адресных). Однако в этом надо разбираться …..
В том числе и в мнемонике, что бы была нагляднее и интуитивно понятнее?????

моя твоя понимай. банить нихт!


очевидно и наглядно, и интуитивно понятно, что получается монстр сложностью на уровне ядра ARM9, и крайне невысокой частотой. с арм9 не сможет конкурировать по частоте. с 8-ми битниками - по сложности.

кстати, где вы найдёте психа, чтобы всё это реализовал?

1. Советую смотреть не на знаки препинания, а на водную гладь - это успокаивает...
2. "есть один. но всеобъемлющий.....Dhrystone" - спасибо...
3. Так не участвуйте....

Чтобы разобраться в сути эффективного доступа к памяти - предлагаю сравнить разные архитектуры на примере A[i]=B[j] для случая, когда стеки, аккумуляторы и прочие регистры(исключая, конечно, регистровый файл на памяти) - "пустые".

привёл бы пример, отчего отталкиваться.


да я то не волнуюсь, а вот модератор... он может и

Господа, хватит о личностях!
Касается всех.

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

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

ИМХО, гораздо более интересная задача для убивания времени, с возможностью "жизни" продукта в будущем - сочинить самый минималистический МК. Чтобы меньше и проще уже ну ни как. 8 разрядов, например. Так как меньше уже совсем нет интереса у пользователей.

Если же есть желание строить высокоэффектиные и производительные МК - смотрите в сторону длинного командного слова типа адрес операнда1 + адрес операнда2 + адрес операнда3 + команда и многопортовое ОЗУ. Всё остальное упрощается до безобразия, нечего будет оптимизировать вообще.

Поэтому ищу/пишу легконастраиваемый компилятор высокоуровневого автокода - чтобы без проблем можно было поменять архитектуру без необходимости переписывать прикладное ПО.


Есть уже у меня 36-разрядное - для Virtex-5 получается ~300LUT и ~100MIPS, а на подходе Spartan-6, у которого вроде те-же 6-входовые LUT-ы...

Уточнил(проект под сукном до написания компилятора) - получаются ~400 6-входовых ЛУТ для системы из ядра с 2К*36 памяти, COM-порта связи с компом(загрузка и запуск программы) и простого VGA контроллера - "helloworld" выводить.

На фтп лежит пакет Lisatek от coware - делает ассемблер и линкер(и еще много чего). Если силами сообщества удастся подобрать ключ к gpg(или pgp точнее не помню), то появится тузла которая из описания ядра поможет сделать на полуавтомате компилятор С

Если мне именяет склероз, на opencores.org есть проект 16-битного стекового процессора с С-компилятором на базе GCC - там, возможно, есть файлы описания архитектуры для кодогенератора. Если есть - можно попробовать взять в качестве козы, так как должны быть хоь некоторое подобие.
На мой взгляд, может и тяжелее придётся, чем ломаной коммерческой тулзой, но перспективнее.

Хочется скрыть уровень машинно-зависимого ассемблера, чтобы упростить переносимость кода, и видеть такую цепочку: ЯВУ --> автокод --> машинные коды. При этом основная оптимизация д/б на уровне ЯВУ --> автокод. Имхо, этот уровень оптимизации может дать самый большой выйгрыш, и имеет смысл попытаться воспользоваться серьезными пакетами разработки ПО - как только подтвердится перспектива.

Автокод - предельно упрощенный машинно-независимый ЯВУ, чтобы 1) легко можно было писать на нем несложные программы, и 2) компилятор на конкретную архитектуру можно было настроить "за пару вечеров" - тогда появится смысл в уникальных ядрах под конкретные задачи. Для этого компилятора важнее компактность и прозрачность исходника, а не оптимизирующие способности - вполне достаточно будет, чтобы не мешал оптимизации на уровне ЯВУ --> автокод (+ делал мелкую оптимизацию типа неполного вычисления логических выражений...). Тут лучше самому написать, имхо, а из готового брать только алгоритмы (только разобраться - не всегда быстрее). Пишу уже.

Проблема - подобрать автокод, удобный для максимально широкого круга ядер. Пример автокода, каким его вижу, уже приводил в другой ветке (N ферзей). Для "безрегистровой архитектуры" вроде удобно, а вот для регистровых/стековых... не ясно пока.

Я вот не пойму смысла этих баталий? Слабо покурить внутреннее устройство GCC, чтобы обнаружить, что сначала он компилит программу в некий псевдокод для виртуальной машины. Вот если генератор из псевдокода в асм для вновь разрабатываемой архитектуры будет требовать минимум извращений, то тогда и архитектура будет оптимальной для поддержки ее гнусем. Это, конечно, при выполнении других условий, например, минимизации количества лутов, или максимального быстродействия, или еще каких, стоящих перед разработчиками.

Кстати, гад по портированию гнуся существует в природе, с вдумчивого изучения этого документа и стоит начать.

Так и хотел сначала , но потом отказался от этого подхода - получим "автомат для бритья"(как в анекдоте - лица у всех разные... до первого бритья).

А что, есть выбор? Кроме гнуся в качестве компилятора яву надеяться не на что, добрый дядя не появится и не подарит оптимизирующий компиллер. Так что - курить до полного просветления маны по гнусю. А иначе это все пустое теоретизирование, которое никогда не принесет никаких плодов.

Имхо, выбор есть - в проектах на FPGA во многих случаях хватит автокода. Оптимизация логических выражений уже есть, оптимизировать распределение переменных не обязательно из-за большого регистрового файла в памяти. Остальную оптимизацию можно выделить в отдельную ступень: автокод --> оптимизатор --> автокод.

Ну до пятисот команд программа без особого напряга пишется на асме. И оптимизируется вручную. А вот больше - тут без яву делать нечего. Конечно, граница "500" - она достаточно условна. Но близка по порядку к объему памяти программ распространенных мелких микроконтроллеров. Как показывает практика, написание программы на яву для таких контроллеров превращается в "написание на Си программы на асме".

И еще одно - компилятор вашего "автокода" тоже добрый дядя напишет? А оптимизатор? Или сами, врукопашную, последовательно наступая на весь набор граблей в компиляторостроении, с выдачей на гора "супероптимизирующего компилятора автокода" лет через 10?

Вообщем - думайте еще. И крепко.

PS Мне кажется, осилить порт гнуся на другую архитектуру (особенно, если есть возможность точить архитектуру под компилятор) не займет более двух месяцев.

[Флуд, не имеющий отношения к теме]

Ближе к делу, Витя. А то точно тему закроют. Вам же десять раз сказали, что новая архитектура без компилятора с ЯВУ не нужна никому. Что будете делать? Или кто его будет делать? Может лучше сразу "на бережку" осознать бесполезность разработки ?! Если конечно это не курсовая работа. Но для курсовой не обязательно прыгать выше головы.

на твой код выставляю свой в 12 байт для 8-разрядного процессора М8 (данные в примере 16-разрядные).
ldw# B Ildw adw @ld ;6 байт
ldw# A Jldw adw @st ;6 байт
Запись типа Форта.
Однако приводя свой пример А(I)=B(J) ты забыл о других операторах присваивания типа-
А=0
А=1234...
А=В
А=un(B )
A=bin(B,C)....
А есть еще условные операторы, циклы, вызовы процедур....
Расставь проценты их использования в типовых программах МК. Раскрой их машинную реализацию в кодах и байтах для своего процессора, как это сделал я для 8-разрядных МК. Умножь их на проценты. И ты получишь рейтинги, которые получил я для МК8051,ПИК,АВР и пр....

А не так:

=16 байт?


Сам и напишу.


- имеются в виду косвенные загрузки

В системе команд процессора М8 команда загрузки имеет длину 1 байт (поэтому 16-4=12).
Вы внимательны, в отличие от других.
Команда загрузки в М8 имеет следующие форматы:
(K) Pildw - текущая страница ОЗУ
(K) PPildw -предыдущая страница ОЗУ
(K) @ldw - косвенная адресация через стек вычислений
(K) Rldw - стек возвратов
(K) @Rldw -косвенная адресация через стек возвратов
(K) @R+ldw -косвенная адресация ПЗУ через стек возвратов
ldw# xxx - загрузка константы
где w - длина данного 1, 2, 4 байта
К - необязательный префикс константы
Мнемоника приведена условно и форматы команд тоже.

Если нет @ldw#, тогда 20 байт получим:

MSP430

20 байт / 12 тактов

однако, как мне кажется
тут

компилятор "догадывается" о том, что такое a и b, то есть это не аналог ли такого:

14 байт/9 тактов ?


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

Огорчили.
1. Описание М8 приведено http://www.moko.ru/mc/
2. Кто сказал, что новая архитектура не нужна никому?
3. Это ваше личное мнение.
4. Промолчу, но прыгну.
Однако. Все это сплошная говорильня, в которой и Вы и я и другие принимаем участие, вместо того, что бы...
Полезность в этом есть, но пользы мало.
Возможно я не смог четко сформулировать свои проблемы и свои их решения. Описание М8 буду править по результатам обсуждения. Но не за день, а за неделю ...две..три..Сейчас написать что либо конкретное уже нет сил, могу только пописывать.

Рекомендую почитать Михаила Козлова из Института высшей нервной деятельности…РАН на близкую тему о «Возможностях универсального кода внутреннего представления программы».....Вот где энергия, настойчивость и сила характера.
http://n-t.ru/tp/ts/uk.htm

Проблемы у нас – это дороги, ...... и кризис.
Однако причем все это? Заполнить пустую строку буковками и отправить их Вам. А оно это нужно?

Имел в виду динамические массивы(адрес первого элемента - не константа). Для статических массивов код у регистровых архитектур будет короче, конечно.

а кому нужна ещё одна ничем не выдающаяся 8-и битная архитектура? что в реё такого действительно необычного заложено, что ею будут активно пользоваться? особо малое количество требуемой памяти для кода? и какой ценой? ценой усложнения самого ядра до умопомрачения? так это сводит на нет всё преимущество от мелкого кода. и тем более такое ядро не будет интересно для FPGA применений. уж скорее Leka своего мутанта доделает и даже продать успеет (результаты то у него интересные получились), чем вы дойдёте хотя бы до стадии HDL-тестирования.