[Leka 0]

...И даже посчитал для М8 бенч 8 на 16 CASE. получил 135 байт без оптимизации (MSP430 198, arm7 - 338, pic18 - 208, atmega 350 с оптимизацией)...

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

//-----------------------
proc switch_case(a)
  var output
  if a = 1
    output = 1 
  elsif a = 2
    output = 2
  ...
  elsif a = 16
    output = 16
  end
  return output
//-----------------------
proc main
  var result
  result = switch_case(16)
  return
//-----------------------

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

Изменено 7 февраля, 2009 пользователем Leka

[Mahagam 0]

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

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

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

 

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

[vitja 0]

попробуйте написать код ....для М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[j] = m1[j];

@+ ldd(IA) @+ std(IB) ;m3[j] = m2[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».

Следующим планирую посчитать КИХ фильтр, но оптимизированный на базе фиксированной, не плавающей арифметики.

 

Ну и что? ..... дает 300 байт):

Код М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-разрядных".

Изменено 8 февраля, 2009 пользователем vitja

[Leka 0]

Для М8 получилась исчезающе малая величина - 21 байт.

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

 

- что дает 135 байт, а не 300. Почти те-же цифры будут и для 16-разрядных данных, и для 32-разрядных.

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

[vitja 0]

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

Да. Байты таблицы следуют сразу за вызовом процедуры (их расположение ТИ не оговорила).

При вызове процедуры адрес возврата записывается в стек. Используя байтовую команду команду 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 * ( 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-разрядного МК для решения задач ЦОС, например, звука. Из байт большая и самая запутанная часть ушла на вычисления адресов, а не самого фильтра.

 

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

Изменено 8 февраля, 2009 пользователем vitja

[Leka 0]

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

 

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

switch(a) {
  case 0x01: return(1);
  case 0x02: return(2);
...

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

Так-что до корректного сравнения ой как далеко.

Изменено 8 февраля, 2009 пользователем Leka

[vitja 0]

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

Со всем согласен.

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

 

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

[Leka 0]

... 64+21=85 по сравнению с 354 байтами АВР это не «исчезающее малая величина» - это просто величина меньшая в 4 раза.

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

... for(i = 0; i < 16*4; i++) m3[i] = m2[i] = m1[i]; ...

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

[vitja 0]

код для М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-адресную систему команд, как наиболее эффективную…. Кто прав – академики из РАН или те, кто предлагает «морэ регистров» для обеспечения совместимости с ЯВУ вместо стековой архитектуры? Вопрос для меня не из простых?

Изменено 10 февраля, 2009 пользователем vitja

[vetal 0]

Почему не cделать М8 за теже деньги, но с большей эффективностью, где Whetstone analysis поддерживается?? Я не понимаю. А вы?

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

[vitja 0]

Потому-что для пика есть средства разработки, а M8 только на бумаге.

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

[vetal 0]

параллельно средства разработки

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

[Mahagam 0]

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

;* 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 * ( 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;

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

 

...совместимой с ЯВУ, удобной для программирования на ассемблере, простой в реализации

и обеспечивающей компактный программный код и малое число тактов на его выполнение...

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

 

Я влез в бенчи, поскольку мне здесь настоятельно посоветовали не пользоваться доморощенным рейтингом, а взять бенчмарки и на них оценить эффективность системы команд М8. Я это сделал за выходные, используя исходники тестов фирмы TI для MSP430, и получил результаты. Оказалось, что эффективность М8 по тестам ТИ превышает эффективность АТMega во много раза, когда по моим рейтингам всего лишь в 1.6 раза (3 раза получилось только для 32-разрядных данных). Кстати, тоже самое, в смысле его эффективности, получили разработчики MSP430 относительно других МК.

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

 

***PS. Мне дали ссылку на Сахару и на Ти/// согласен/// в помойку их///

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

 

Остальное я упоминал – первое это минимальный объем кода, остальное - эффективная реализация в аппаратуре (в тактах, площади, потреблении…)

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

[vitja 0]

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

"У людей не хватает времени что-либо узнавать/ Они покупают вещи готовыми в магазинах"/ где ///

Так сказал Лис/// "Антуан/ёёёёё////

За ссылку на тесты спасибо/ Однако нельзя ли ближе к 8-разрядным МК? без флоат и транспортирования матриц/

Дайте честные тесты характерные для 8-разрядных МК/ без оптимизации как в ТИ//

Три или 5 тестов с исходниками на Си и оценками затрат программного кода для известных 8-разрядных МК (без Сахары)/

Буду благодарен///

За абракадабру извините/ Не придумал еще символики понятной для /// и интуитивной для умных/

 

 

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

Я даже очень оцениваю////Но нельзя ставить телегу впереди лошади как Вы предлагаете//

Нет системы команд/// нет прочего ////Включитесь в предыдущий этап - поучаствуйте в создании систему команд

для 8-разрядного МК (стекового)/ Предложите//// Однако Спасибо

[zltigo 1]

Не придумал еще символики понятной для /// и интуитивной для умных/

 

Мoderator:

 

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