[quote="Hishnik"]А они по тестам все только на Dhrystone?[/quote]Еще в планах CoreMark, но пока не могу скомпилировать, все никак не дойдут руки до указателей на функции в трансляторе Си-в-Форт.

Ради интереса калькуляторный тест с ферзями отсюда [url]https://www.hpmuseum.org/cgi-bin/articles.cgi?read=700[/url] запускал. В самопальном интерпретаторе Бейсика, который скомпилирован не менее самопальным компилятором Си-в-Форт. Тем не менее, у 4-битных результаты не хуже, чем у профессиональных процессоров и интерпретаторов Бейсика. Могу и в каком-нибудь 3-битном прогнать.

А вообще в 3-битные пока шил только Dhrystone и Basic, но в теории должно все запуститься, в т.ч. и игры из соседней темы про консольные войны.

Что касается Dhrystone, то бытует мнение, что тест уже устарел, в т.ч. и потому, что очень уж хитрыми стали компиляторы: порой в результате оптимизаций кромсают этот тест настолько, что результаты слишком уж неприличными становятся. Например, если верить этой странице [url]http://www.roylongbottom.org.uk/dhrystone%20results.htm[/url], то некоторые i7 тратят на одну итерацию теста Dhrystone меньше сотни тактов (делим тактовую на DMIPS/s и на 1757). Ну не может быть такого. Там в тесте несколько строк на 30 с лишним символов каждая, которые на каждой итерации копируются/сравниваются, а еще есть структуры примерно такого же размера, которые тоже копируются, и т.д. и т.п. Ну и сами процессоры уже многоядерные, плюс частоту могут менять на лету, так что тут Dhrystone для оценки производительности и сравнения современных процессоров уже не очень-то и пригоден. Вот, например, чудовищное: :)[code] Dhry1 Dhry1 Dhry2 Dhry2
Opt NoOpt Opt NoOpt
VAX VAX VAX VAX
CPU MHz MIPS MIPS MIPS MIPS
Later Results 32 and 64 Bit MS Compilers
Core i7 64b1 &&&& 33048 18355
b1 = 32 bit integers, b2 = 64 bit integers
&&&& overclocked i7-3930K see above[/code]3930MHz/33048/1757=68 тактов на итерацию Dhrystone :)
Но в моем случае компилятор простой как 3 копейки. То же самое можно сказать про процессор. Он честно от и до считает весь тест за честные несколько тысяч тактов. И для сравнения самодельных процессоров между собой подходит как нельзя лучше. Именно в таком качестве его и использую: сравниваю разные системы команд между собой.
Но это не отменяет того факта, что некоторые из самоделок не уступают первым Пентиумам на этом тесте :)

А они по тестам все только на Dhrystone?

Прогнал на скорую руку, наверное, пару десятков разных вариантов с литералами. Самый компактный код пока получается с литералами 0-3/u7/word[code]0-3 [010][0xx] 2 такта
u7 [010][10x][xxx][xxx] 4 такта
word [010][11x][xxx][xxx][xxx][xxx][xxx] 7 тактов[/code]А самый быстрый с литералами 0-3/u6/u12/word[code]0-3 [010][0xx] 2 такта
u6 [010][100][xxx][xxx] 4 такта
u12 [010][101][xxx][xxx][xxx][xxx] 6 тактов
word [010][11x][xxx][xxx][xxx][xxx][xxx] 7 тактов[/code]По скорости и плотности кода все они примерно одинаковые (в диапазоне 1160-1205 Dhrystones/s @20MHz и 32255-38425 команд), в т.ч. и вариант с завершающим нулем в старшем бите. Вариант с длиной литерала помедленнее, но приемлемо. А вот версия с полными литералами совсем слабая. Самое удивительное лично для меня, что лучшие представители 3-битных процессов лишь в 2-4 раза уступают 4-битным по скорости и даже превосходят некоторые из них по плотности кода. Думал, если честно, что пропасть между ними будет огромная по всем параметрам.[code]cpu MHz Dhry s D/s DMIPS /MHz size
f30 20 256 7.658 33 0.02 0.00 62354x3=187062 1-17 тактов 0-3/push
f31 20 16384 30.229 542 0.31 0.02 49320x3=147960 7 тактов word
f3N 20 16384 14.785 1108 0.63 0.03 33517x3=100551 2-8 тактов с длиной
f3Z 20 16384 13.766 1191 0.68 0.03 34732x3=104196 2-9 тактов с завершающим нулем
f38 20 16384 13.702 1196 0.68 0.03 32255x3= 96765 2-7 тактов 0-3/u7/word
f3H 20 16384 13.598 1205 0.69 0.03 33625x3=100875 2-7 тактов 0-3/u6/u12/word

f46 20 16384 6.401 2560 1.46 0.07 29097x4=116388 1-9 тактов
f43 20 16384 4.769 3436 1.96 0.10 19617x4= 78468 1-5 тактов
f4A 20 16384 3.746 4374 2.49 0.12 23707x4= 94828 1-6 тактов[/code]Здесь для сравнения самый первый вариант процессора (f30), с полными литералами (f31), с длиной (f3N), завершающим нулем в старшем бите (f3Z), а также с самым компактным кодом (f38) и самый быстрый (f3H). А из 4-битных тут самый быстрый (f4A), с компактным кодом (f43) и самый слабый по скорости и плотности (f46), у него 50% воды в литералах, сложение вместо умножения с накоплением и 2/ вместо rshift. В столбце size размер прошивки в битах.
Да, кстати, в двух освободившихся слотах команды rshift и pick. Связка pick+call/ret совсем слабой оказалась, а вариант rshift+call/ret раза в 3 медленнее в сравнении с rshift+pick.

Пара новых мыслей по мотивам вчерашних излияний :)

Литералы с завершающим нулем в 4-битном варианте можно еще слегка утрамбовать.
Вместо[code] [0100][1xxx] .... [0xxx] 2-7 тактов[/code]такое:[code]u3 [0100][0xxx] 2 такта
u6 [0100][1xxx][0xxx] 3 такта
u9 [0100][1xxx][1xxx][0xxx] 4 такта
u12 [0100][1xxx][1xxx][1xxx][0xxx] 5 тактов
word [0100][1xxx][1xxx][1xxx][1xxx][xxxx] 6 тактов[/code]Т.е. неявное завершение нулем 5-й тетрады. Ну а чего? Когда 4 тетрады (т.е. 12 бит из 16) уже обработано, а нуля все еще нет, значит пора и честь знать: недостающие 4 бита будут в следующей тетраде и баста.

И комбинированный вариант для 3-битных процессоров чуть подсократить.[code]0 [010][000] 2 такта
u3 [010][001][xxx] 3 такта
u6 [010][010][xxx][xxx] 4 такта
u9 [010][011][xxx][xxx][xxx] 5 тактов
u12 [010][100][xxx][xxx][xxx][xxx] 6 тактов
1 [010][101] 2 такта
word [010][11x][xxx][xxx][xxx][xxx][xxx] 7 тактов[/code]Эти варианты должны получиться достаточно хорошими по плотности и скорости для процессоров, в которых только один вид литералов, но пока не проверял. Еще миллион вариантов можно придумать, например, с четырьмя двухтактовыми литералами 0-3 и четырьмя возможными размерами для всех прочих литералов. Кстати, замена одного представления литералов на другое практически не меняет потребление ресурсов ПЛИС. Регистры (FF) так и болтаются в диапазоне 65-70 штук, а количество LUT скачет на пару десятков туда-сюда. А, для примера, одна лишь замена команды 2/ на rshift сразу сжирает 150-200 LUT.

Еще забавно, что в процессорах с 3-битными командами сейчас задействовано только 6 из 8 команд: lit @ ! jz nand -. Может еще какие-то лишие? :)

А дальше добавлять call/ret или pick/rshift. Или даже call/ret в одном опкоде сделать. Если call по адресу 0, то это не call, а ret, т.к. обычной программе по этому адресы прыгать незачем.

:) О, да. Литералы - это вселенское зло, борьба с которым идет испокон веков. Ведь программа для форт-процессоров состоит из них чуть менее, чем полностью. Как раз в этом направлении немного поэкспериментировал на днях, правда на 4-битных системах команд.
В самом простом варианте была команда push и от 0 до 8 команд 0/1/2/3[code]push [0100][00xx] .... [00xx] 1-9 тактов[/code]Еще был вариант с командами 0/nibble/byte/u12/word под каждый из возможных размеров литерала (можно задействовать лишь часть из них, но тогда код пухнет и замедляется)[code]0 [0000] 1 такт
nibble [0001][xxxx] 2 такта
byte [0010][xxxx][xxxx] 3 такта
u12 [0011][xxxx][xxxx][xxxx] 4 такта
word [0100][xxxx][xxxx][xxxx][xxxx] 5 тактов[/code]Минус первого варианта в том, что в литералах 50% воды. Второй в этом смысле существенно лучше, дает близкий к идеальному по плотности код. Да, можно еще плотнее, если добавить отдельные команды для 1 и некоторых других литералов, но их уже и без того слишком много :) Аж 5 опкодов из 16 сжирают литералы в этих системах команд.

Какие еще могут быть способы борьбы с литералами?
Наример, полный литерал, но оно жирное и медленное[code]word [0100][xxxx][xxxx][xxxx][xxxx] 5 тактов[/code]Команда (пока без названия), за которой длина литерала и следом сам литерал[code] [0100][len ][xxxx] .... [xxxx] 2-6 тактов[/code]Команда (тоже без названия), за которой литерал 3-битными порциями, а старший бит тетрады - признак конца литерала[code] [0100][1xxx] .... [0xxx] 2-7 тактов[/code]И еще интересный вариант (тут несколько разных исполнений может быть) на базе литералов с длиной: команда (по традиции без названия), за которой либо ниббл, либо длина литерала. А все потому, что возможных длин всего 4 штуки, но можно и меньшим числом обойтись. Тогда, например, наиболее часто используемые короткие литералы (например, 0-10 и 15) будут кодироваться двумя нибблами, а значения 11-14 будут обозначать длину 1-4 прочих литералов.[code]0-10,15 [0100][xxxx] 2 такта
nibble [0100][1011][xxxx] 3 такта
byte [0100][1100][xxxx][xxxx] 4 такта
u12 [0100][1101][xxxx][xxxx][xxxx] 5 тактов
word [0100][1110][xxxx][xxxx][xxxx][xxxx] 6 тактов[/code]Кстати, у текущего лидера в Dhrystone 3 вида литералов: 0, 1 и (без названия)[code]0 [0000] 1 такт
1 [0011] 1 такт
2-15 [0100][xxxx] 2 такта
byte [0100][0000][xxxx][xxxx] 4 такта
word [0100][0001][xxxx][xxxx][xxxx][xxxx] 6 тактов[/code]

Для 3-битных команд на ум приходят примерно те же варианты.
Сейчас[code]push [010][00x] ... [00x] 1-17 тактов[/code]Полный литерал[code]word [010][00x][xxx][xxx][xxx][xxx][xxx] 7 тактов[/code]С длиной[code] [010][len][xxx] ... [xxx] 2-8 тактов[/code]С завершающим нулем в старшем бите[code] [010][1xx] ... [0xx] 2-9 тактов[/code]Комбинированный[code]0 [010][000] 2 такта
1 [010][001] 2 такта
u3 [010][010][xxx] 3 такта
u6 [010][011][xxx][xxx] 4 такта
u9 [010][100][xxx][xxx][xxx] 5 тактов
u12 [010][101][xxx][xxx][xxx][xxx] 6 тактов
u15 [010][110][xxx][xxx][xxx][xxx][xxx] 7 тактов
word [010][111][00x][xxx][xxx][xxx][xxx][xxx] 8 тактов[/code]Кстати, с нормальными литералами освободится 2 опкода. И тут вопрос, что сюда лучше воткнуть: call/ret или все же pick и 2/?

Насколько распухнет реализация, если литералы сделать "по-нормальному"? Типа команда 1 - это литерал, за ней длина литерала (1-8 трёхбитных слов), а потом сам литерал:
1 0 1 => 1
1 1 1 0 => 8
1 2 1 0 0 => 64

В скомпилированном Dhrystone 55441 команд:[code]0 0 18275
1 1 22469
2 push 8084
3 jz 499
4 @ 2028
5 ! 2839
6 nand 392
7 - 825
[/code]Хех, код на 88% состоит из литералов (команды 0, 1 и push), а в самих литералах 67% "воды", почти как в человеке :)
Если пожать Хаффманом (дерево строил вручную, может где-то и ошибся, но не принципиально), то получим:[code]0 00 18275x2= 36550
1 1 22469x1= 22469
2 010 8084x3= 24252
3 0110100 499x7= 3493
4 01100 2028x5= 10140
5 0111 2839x4= 11356
6 0110101 392x7= 2744
7 011011 825x6= 4950
115954 бит[/code]А сейчас длина прошивки[code] 55411x3=166233 бит[/code]Т.е. примерно в 1.5 раза пожмется.
Только вот регистр pc у нас 16-битный, адресует 64K 3-битных команд. А для Хаффмана ячейки станут "однобитными", фактические адреса сразу придется домножать на 3 (это сразу 1-2 бита в плюс к каждому адресу, а значит дополнительно 1-4 бит к каждому такому литералу в "новой" системе команд), код разбухнет, так что еще неизвестно, какой вариант в итоге более компактным окажется. :) Да и не покроет теперь 16-битный pc 115K адресов. При этом даже в самом простом процессоре с 4-битными командами прошивка весит 80K бит, а в более продвинутых меньше 60K.

С представлением команд можно дойти и до кодирования Фано (которое префиксное). Тогда команды будут занимать от 1 бита и до... многих (сколько нужно). Тут будет довольно интересно в плане разработки КА, у которого 0 будет командой, а 1 - префиксом (и далее 00 - еще команда, а 01 - префикс). Вряд ли для практических целей такое будет сильно полезно, но показательно в части того, сколько вообще места может занимать команда.

Вот что бывает, когда человеку в пятницу вечером нечем заняться :D

Когда-то давно посещала мысль ([url]https://fforum.winglion.ru/viewtopic.php?p=51365#p51365[/url]), что форт-процессор на 8 команд тоже заведется. Ну, короче, завелся с такой системой команд:[code]0 1 push jz @ ! nand -[/code]Тут литералы набиваются командой push, за которой следует от 0 до 16 ноликов/единичек, через nand делаются побитовые операции, из вычитания делаем сложение, а потом через многократные маски, сравнения и сложения делаем умножение и shr, ну а call/ret делаем программно.
Проект под Tang Nano 9K: http://totalvacuum.ru/F30/16f30.zip
Само ядро сжирает 50 регистров (FF) и суммарно меньше 300 LUT (LUT+ALU+SSRAM), т.е. не сильно-то и меньше в сравнении с 4-битными Форт-процессорами, но вот код прошивок при этом жиреет в несколько раз, а производительность падает раз в 100(!). При желании можно пересобрать Dhrystone через rebuild.bat в папке FIRMWARE.[code]CPU MHz Dhry s Dhry/s DMIPS DMIPS/MHz
f30 20 256 10.138 25 0.01 0.00[/code]
[img]http://totalvacuum.ru/F30/dhryf30.jpg[/img]
[url=http://totalvacuum.ru/F30/dhryf30.jpg]ссылка на изображение[/url]
Да, кстати, исходный вариант Dhrystone в скомпилированном виде весил 69K 3-битных команд, т.е. чуточку не влезал в 64K, пришлось чуть сократить вывод в терминал, чтобы влезло. :)

Потребление ресурсов ПЛИС мне сложно как-то оценить. Я в этом мало что понимаю и многие вещи делаю по наитию. Наверняка есть куча способов/приемов, как уменьшить потребление ресурсов и/или увеличить максимальную тактовую частоту.

С двухбитными командами, наверное, процессор не придумать. :) Но вот интересно, при каком количестве бит на команду будет достигнута максимальная плотность кода. С производительностью все более-менее понятно: чем больше разрядность команды, тем быстрее будет код, другой вопрос, что при переходе с 3 бит на 4 скорость вырастает в сотни раз, а при переходе c 4 бит на 6 лишь в несколько раз, дальше, наверное, с каждым увеличением на 1 бит будет прирост на проценты, потом на доли процента... Ну а с плотностью тут сложно спрогнозировать: 3-битный код в разы жирнее 4-битного, 6-битный чуточку плотнее, чем 4-битный. Возможно, что максимум плотности кода будет, например, на 5-битных командах (как в процессоре F21 [url]https://www.ultratechnology.com/f21cpu.html[/url]). А может и где-то после 6 бит, например, на 7/8/9-битных командах (например, проц от whiteTigr [url]https://habr.com/ru/articles/149686/[/url]). Или даже на 16/18-битных командах (как в J1 [url]https://marsohod.org/39-m02mini-prj/410-forth-j1[/url]). Вот где, интересно, эта оптимальная с точки зрения плотности кода длина команды? При условии, что мы говорим о Форт-процессорах и разрядность процессора у нас, допустим, 16 бит.

Выдалась свободная минутка, перепрогнал Dhrystone через свои процессоры, ибо мой компилятор Си-в-Форт чуточку повзрослел.[code]CPU MHz Dhry s Dhry/s DMIPS DMIPS/MHz
f41 20 16384 6.236 2627 1.50 0.07
f45 20 16384 6.006 2728 1.55 0.08
f42 20 16384 5.581 2936 1.67 0.08
f43 20 16384 4.997 3279 1.87 0.09
f44 20 16384 4.491 3648 2.08 0.10
f44x6 20 16384 1.936 8463 4.82 0.24
f61 20 16384 1.858 8818 5.02 0.25

Dhry2 Dhry2
Opt NoOpt
VAX VAX
CPU MHz MIPS MIPS
AMD 80386 40 13.7 4.53 0.11-0.34
IBM 486D2 50 22.4 7.89 0.16-0.45
80486 DX2 66 35.3 12.4 0.19-0.53
IBM 486BL 100 40.9 11.8 0.12-0.41
AMD 5X86 133 84.5 9.42 0.07-0.64
Pentium 75 87.1 18.9 0.25-1.16
...
Core 2 Duo 1 CP 2400 6446 1251 0.52-2.69
Core i7 4820K 3900 11867 1981 0.51-3.04[/code]Процессор с 4-битными командами уже на пределе (f44x6), маловероятно, что в плане производительности удастся выжать из него еще хоть что-то. Разве что оптимизации добавлять в компилятор или систему команд чуть более удачную придумывать. А вот у процессора с 6-битными командами есть огромный резерв и простор для творчества (перечислю только основные моменты):
- сама система команд, есть несколько вариантов, в "железе" пока реализована самая простая (и медленная);
- 2 свободных слота в текущей системе команд;
- при трансляции Си-в-Форт сишные циклы for/while/do-while транслируются в jz/jmp, а намного более быстрые аппаратные циклы while-repeat и do-loop не задействованы;
- и, наконец, никто не запрещает выполнять по несколько команд за такт (как и в f44x6), ну а пока читается по 3 команды за такт (задел на будущее, можно и 6 сделать), но выполняется пока ровно по одной;
Ну а еще сам компилятор. Все же Dhrystone оценивает не производительность процессора, а производительность связки процессор+компилятор. И тем удивительнее, что даже в таком сыром виде творческий союз "самодельный процессор"+"самодельный компилятор" не проигрывает тандему "серийный процессор"+"профессиональный компилятор".

upd. Для коллекции процессор с 6-битными командами и литералами за 1-2 такта, пока еще в зачаточном состоянии, но пусть будет[code]CPU MHz Dhry s Dhry/s DMIPS DMIPS/MHz
f61x3 20 16384 1.762 9299 5.29 0.26[/code]Код программы нарезан на 18-битные порции (куски по 3 6-битных команды), 2 такта на литерал получается, если литерал целиком не помещается в текущее 18-битное слово и наползает на следующее. Кроме литералов ничего не делал.

:) Кстати, наткнулся тут и вспомнил, откуда тестовая 3d-бродилка взялась.
[img]http://totalvacuum.ru/gfx.jpg[/img]
[url=http://totalvacuum.ru/gfx.jpg]ссылка на изображение[/url]
Она там была в нескольких вариантах на Си, взял первую из них и перевел на Форт, попутно заменив float на int. Если мне не изменяет склероз, там же были сразу варианты с fixed point и текстурами.

[quote="Hishnik"]Ого! Это серьезно.
Тут ведь еще какой интересный вывод получается. Вот в рамках одного архитектурного подхода получился набор ядер. Они показали существенно разные характеристики на Dhrystone. В принципе понятно, что там можно менять, чтобы они были еще лучше. Теперь можно пойти дальше и распространить подход на тесты, имитирующие реальные задачи. Будет аналогично - базовое ядро, тесты, модификация для улучшения характеристик в нужную сторону.[/quote]Ну я в основном занимался не затачиванием процессора под Dhrystone, а ускорением традиционных для Форта примитивов, которым по понятным причинам не хватило места в системе из 16 команд. Вот в дополнение к предыдущему варианту добавил в f44x6 за такт 15 rshift (знак числа), n *, invert (dup nand), < (- 15 rshift). В результате стало еще чуточку быстрее:[code]CPU MHz Dhry s Dhry/s DMIPS DMIPS/MHz
f44x6 20 16384 2.060 7953 4.53 0.23[/code]Ну и есть понимание, чего примерно можно ожидать от процессора с чуть более широкой системой команд, в котором все базовые примитивы будут из коробки. Другими словами, я пытался нащупать некий гипотетический потолок производительности для Форт-процессоров с достаточно широким машинным словом, при этом, однако, держал в уме, что компилятор совсем слабый, а, следовательно, с коммерческим компилятором результаты должны быть гораздо выше. Ну а вообще можно двигаться как в сторону увеличения количества одновременно выполняемыых за такт команд или же увеличения количества ядер, так и в сторону увеличения разрядности машинного слова. И видно, что, например, даже небольшие (и практически бесплатные с точки зрения потребления ресурсов ПЛИС) изменения (2 команды за такт в f42x2) приводят к существенному росту скорости. Как и расширение машинного слова с 4 до 6 бит, в результате чего например f61, который выполняет ровно по одной команде, в 2-3 раза опережает обычные процессоры с 4-битными командами, да и не сильно отстает от раскочегаренного до неприличия f44x6. Причем это самый первый и самый простой вариант 6-битного процессора, есть и другие более навороченные, но они пока не завелись в ПЛИС. А так да, когда на горизонте забрезжит какая-то реальная задача, то система команд будет затачиваться именно под нее, в т.ч. добавлением новых команд, может даже экзотических. Но это на случай. если вдруг процессор общего назначения перестанет справляться.

Но главное, что удалось убить сразу несколько зайцев (шучу, ни один заяц при съемках не пострадал):
- убедился, что компилятор Си успешно транслирует достаточно сложный исходник, который (это тоже важно) был написан другим человеком;
- обнаружил (не без удивления), что мои процессоры не сильно проигрывают обычным серийным процессорам, за такие цифры не стыдно, более того, есть понимание, что если здесь вдруг появится возможность использования коммерческого компилятора с тучей возможных оптимизаций (например, которые транслируют в условный llvm или в webassembly), то результаты, естественно, окажутся еще более впечатляющими, кстати, никто ведь не запрещает использовать Форт и Форт-ассемблер, результат в моем случае почти всегда оказывается более быстрым и компактным, если сравнивать с выхлопом от моего транслятора Си;
- увидел, что связка свой-процессор/свой-компилятор (Си, Форт или любой другой) вполне жизнеспособна, даже когда процессор до неприличия простой, а компилятор Си даже не умеет константные выражения на этапе компиляции вычислять, про какие-либо оптимизации я вообще молчу, тем не менее, рано или поздно оптимизации появятся, вижу много мест, где транслятор должен рожать более красивый код;
- получил инструмент, при помощи которого можно сравнивать между собой разные системы команд, раньше сравнивал при помощи 3d-бродилки, и хотя корреляция между тестами есть, но доверия к общепризнанному инструменту чуточку больше :)

Ого! Это серьезно.
Тут ведь еще какой интересный вывод получается. Вот в рамках одного архитектурного подхода получился набор ядер. Они показали существенно разные характеристики на Dhrystone. В принципе понятно, что там можно менять, чтобы они были еще лучше. Теперь можно пойти дальше и распространить подход на тесты, имитирующие реальные задачи. Будет аналогично - базовое ядро, тесты, модификация для улучшения характеристик в нужную сторону.

[quote="KPG"]Стандартный Cи тест [url=https://github.com/eembc/coremark]Coremark[/url]
(для Forth тоже был перенесён и были измерения в местном топике Бенчмарка Форт систем)

P.S. Таблица на сайте измерения для разных кристалов https://www.eembc.org/coremark/scores.php[/quote]Coremark пока не компилируется, т.к. до сих пор не дошли руки до указателей на функции в моем трансляторе.

Но зато с полпинка завелся тест Dhrystone. Наконец-то добрался до платы с ПЛИС и прогнал Дрыстоний через свои процессоры:[code]CPU MHz Dhry s Dhry/s DMIPS DMIPS/MHz
r81 20 16384 6.126 2675 1.52 0.08
f41 20 16384 7.484 2189 1.25 0.06
f42 20 16384 6.637 2469 1.41 0.07
f43 20 16384 5.466 2997 1.71 0.09
f44 20 16384 4.920 3330 1.90 0.09
f42x2 20 16384 4.620 3546 2.02 0.10
f43x6 20 16384 3.907 4193 2.39 0.12
f44x6 20 16384 2.120 7728 4.40 0.22
f61 20 16384 2.541 6448 3.67 0.18

Core 2 Duo E8500 3160 1M 0.440 1294 0.41
vax 11/780 5 1757 1 0.20

Dhry2 Dhry2
Opt NoOpt
VAX VAX
CPU MHz MIPS MIPS
AMD 80386 40 13.7 4.53 0.11-0.34
IBM 486D2 50 22.4 7.89 0.16-0.45
80486 DX2 66 35.3 12.4 0.19-0.53
IBM 486BL 100 40.9 11.8 0.12-0.41
AMD 5X86 133 84.5 9.42 0.07-0.64
Pentium 75 87.1 18.9 0.25-1.16
...
Core 2 Duo 1 CP 2400 6446 1251 0.52-2.69
Core i7 4820K 3900 11867 1981 0.51-3.04[/code]Для сравнения здесь же приведены цифры по "эталонному" vax11/780, core 2 duo e8500, под который скомпилировал своим транслятором и по другим процессорам (взято отсюда [url]http://www.roylongbottom.org.uk/dhrystone%20results.htm[/url]).

Из моих в списке risc c 8-битными командами (по 4 бита на код команды и register/immediate) и форт-процессоры с 4- и 6- битными командами. Процессоры f42x2/f43x6/f44x6 выполняют в точности ту же прошивку, что f42/f43/f44 соответстенно. Но f42x2 умеет выполнять одновременно до 2 команд за такт (команды 0-3, push/0-3 или push/push), f43x6 умеет за такт до 6 команд, в т.ч. n(литерал)/n call/n jz/dup(0 pick), ну а f44x6 - те же, что и в f43x6, плюс n +/n -/n @/n !/drop(0 * -)/over(1 pick)/nip(swap 0 * -), в результате работают заметно быстрее.



[img]http://totalvacuum.ru/dhryf61.jpg[/img]
[url=http://totalvacuum.ru/dhryf61.jpg]ссылка на изображение[/url]

Игры с внутренними регистрами в целях улучшить показатели в синтетических тестах в конечном итоге не дают практической пользы. Если разобраться, в итоге это приводит к добавлению аппаратного ядра, которое и выполняет основную работу, и тут его стоит аккуратно "отцепить" от процессора, чтобы не делать из универсального устройства компонент, который по сути будет крутиться в цикле CMD1 CMD2. В принципе есть варианты ускорения циклов и часто встречаются дополнительные флаги "одновременно с этой командой делать ret". Но такие флаги начинают расползаться по системе команд, портя ее внутреннюю согласованность.