Как сделать форт-процессор 2022

Total Vacuum

Про циклы
Имеется 2 системы команд (с поддержкой аппаратных циклов и без):

Код:

while repeat do loop word jz call ret @ ! swap pick nand - mla rshift
xxxxx xxxxxx xx xxxx word jz call ret @ ! swap pick nand - mla rshift

3d-бродилка на варианте с традиционными программными циклами через jz выдает 56fps, а в варианте с аппаратными циклами выходит 78fps, т.е. быстрее в 1.4 раза.
То же самое, но литералы/jz/call за такт: 190 vs 237 fps, прирост в 1.25 раз.
При этом чем короче тело цикла, тем больше прирост скорости.
Накладные расходы на программную реализацию do-loop составляют 12-18 тактов на итерацию, а в варианте с аппаратными циклами - 1 такт на итерацию.
Забавно, что кроме прироста скорости получаем и уменьшение размера кода, что в свою очередь потенциально может приводить к дополнительному приросту скорости

Посему аппаратным циклам в новом процессоре с 6-битными командами быть

Про длинное машинное слово
Сейчас для упреждающего чтения команд в блоке always @ (negedge c) используется длинное и жуткое

Код:

cmd = {code[pc+7],code[pc+6],code[pc+5],code[pc+4],code[pc+3],code[pc+2],code[pc+1],code[pc]};

Оно мало того, что жутко выглядит, так еще и ресурсы ПЛИС активно поджирает: по 1 блоку BRAM для каждой пары прочитанных команд, потребление других ресурсов также заметно растет.
Появилась мысль сделать сразу длинное командное слово, например, 16 или 32 битное (сами команды как и прежде остаются 4-битными). И читать (при необходимости) за раз по 2 таких слова. Адрес слова будет определяться через pc>>3 (для 32-битных слов), а положение текущей команды в прочитанном машинном слове - через отстаток от деления pc на 8. Пока не проверял, но есть подозрения, что расхода (дополнительного) BRAM не будет, а потребление других ресурсов уменьшится.

KPG

Total Vacuum писал(а):

Отставание от ARM всего в 1.17 раз на упрощенном тесте.

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

Отличные показательные цифры в бенче достигнуты

P.S. А, для симуляции по такому принципу "AVR" придётся делать 32-а быстрых регистра в памяти,
а для PIC - 256?
Кстати, интересно, а команды перехода по флагу переноса не рассматривались для включения в список команд.
(т.к. в обычных контроллерах обычно есть сдвиги через флаг переноса, а в AVR ещё и отдельный флаг T, кроме знакового)

Total Vacuum писал(а):

Посему аппаратным циклам в новом процессоре с 6-битными командами быть

И команде For?

6-ть бит, как понимаю, тоже некоторый компромис?

Total Vacuum

KPG писал(а):

Отличные показательные цифры в бенче достигнуты

Это не предел, будет лучше

KPG писал(а):

А, для симуляции по такому принципу "AVR" придётся делать 32-а быстрых регистра в памяти,
а для PIC - 256?

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

KPG писал(а):

Кстати, интересно, а команды перехода по флагу переноса не рассматривались для включения в список команд.
(т.к. в обычных контроллерах обычно есть сдвиги через флаг переноса, а в AVR ещё и отдельный флаг T, кроме знакового)

Пока только jz/jnz в почете, Но можно, наверное, придумать команду cmp, которая будет возвращать результат сравнения всевозможными способами двух операндов, каждый бит результата будет соответствовать какому-нибудь флагу, дальше побитовая маска и jz/jnz. Если ничего не путаю, нечто подобное в RISC-V сделано.

KPG писал(а):

И команде For?

Хотя цикл со счетчиком и называется цикл do-loop (так исторически сложилось), но по смыслу он ближе к for-next, впрочем не один в один. Например,

Код:

4 do dup . loop \ печатает 3 2 1 0

Т.е. у меня это цикл с автодекрементом до 0, но счетчик лежит на вершине стека данных.
while-repeat, кстати, тоже не точная копия фортовского.

KPG писал(а):

6-ть бит, как понимаю, тоже некоторый компромис?

Там смысл в том, что в тех ПЛИС, которые у меня есть (Spartan-3 и Gowin), BRAM состоит из 18-битных ячеек, т.е. можно утрамбовать по 3 команды в ячейку. А если команды 4-битные, то трамбуется 4 команды, т.е. 16 бит, а 2 бита остаются неиспользуемыми. Ну а кроме того 6-битная команда позволяет утрамбовать туда весь uf \ micro forth \

KPG

Total Vacuum писал(а):

Ну а кроме того 6-битная команда позволяет утрамбовать туда весь uf \ micro forth \

Тут ещё для размышления можно глянуть на эзотерческий стековый язык GolfScript

(может что то в его дизайне понравится)

P.S. Немного решённых на нём задач https://rosettacode.org/wiki/Category:Golfscript

Бывает используется и для составления решений на https://codegolf.stackexchange.com/

KPG

Не Форт процессор, но авторский проект 16-ти битного процессора на минимальном количестве дискретных TTL микросхем (8-ми)
(при использовании 1-го битного ALU и последовательной памяти для их минимального количества)

Проектируем самодельный 16-битный CPU в 2023 году

Цитата:

Для создания 16-битного последовательного CPU нужно всего 8 интегральных схем, включая память и тактовый генератор. Он имеет 128 КБ SRAM, 768 КБ FLASH и его можно разгонять до 10 МГц. Он содержит только 1-битное АЛУ, однако большинство из его 52 команд работает с 16-битными значениями (последовательно). На своей максимальной скорости он исполняет примерно 12 тысяч команд в секунду (0,012 MIPS) и, среди прочего, способен выполнять потоковую передачу видео на ЖК-дисплей на основе PCD8544 (Nokia 5110) с частотой примерно 10 FPS.

P.S. Интересно, что микросхемы последовательной флэш памяти за 100МГц
Например 25q32 но утилизироать их скоростные возможности,
вероятно можно только с FPGA и/или где к ним сделана аппаратная поддержка Quad-SPI (QSPI)

Использованная в проекте выше W25Q80 тоже похоже с такими характеристиками (6нс - максимальное время доступа)

Последовательная SRAM память 23LC512 (в проекте 2-е микросхемы)

А, здесь BIT SERIAL CPU and TOOL-CHAINна FPGA с Форт.

KPG

Total Vacuum писал(а):

Это не предел, будет лучше

Стандартный Cи тест Coremark
(для Forth тоже был перенесён и были измерения в местном топике Бенчмарка Форт систем)

P.S. Таблица на сайте измерения для разных кристалов https://www.eembc.org/coremark/scores.php
Когда то в этом Бенче были и данные по стековому процессору PSC1000 Ignite.pdf (от Patriot Scientific)
igniteIP_20050506.pdf
(0,13 микрон 600МГц)

Для PSC1000 Ignite был и Си компиляор для Win/Linux (в Веб архиве от 2003г не сохранены)

Total Vacuum

Что ж, продолжим...

Имеется система команд

Код:

xxx xxx xxx abs word jz call ret @ ! dec dup inc - + jnz

и раскочегаренный процессор, который выполняет за такт

Код:

n
n call
n jz
n +
n -
n @ \ для адресов 0-15
n ! \ для адресов 0-15
n inc \ для адресов 0-15
n dec \ для адресов 0-15
n abs

Проигрыш ARM в режиме его "эмуляции" составляет 1.17 раз.
Далее последовательно делаем за такт:

Код:

n @ @ \ проигрыш в 1.11 раз
- dup \ проигрыш в 1.04 раза
- - \ проигрыш в 0.98 раз, т.е. уже процента на 2 быстрее, чем ARM :)

Если посмотреть на код (сгруппированы 4-битные команды, которые выполняются за такт)

Код:

40000 400099             [2] 0 r1 !                 [1] MOV R1,#0
40000 4000D9             [2] 0 r0 !                 [1] MOV R0,#0
40000 4000B9             [2] 0 r6 !                 [1] MOV R6,#0
                         [ ] `: line40`             [ ] LINE40:
400098 40008D            [2] r1 @ r3 -              [1] CMP R1,R3
400D05                   [1] `line180` jz           [3] BEQ LINE180
4000B8 400098 9          [3] r6 @ r1 @ !            [?] STR R6,[SP,R1,LSL #2]
40009C                   [1] r1 inc                 [1] ADD R1,R1,#1
40008 4000B9             [2] r3 r6 !                [1] MOV R6,R3
                         [ ] `: line70`             [ ] LINE70:
4000DC                   [1] r0 inc                 [1] ADD R0,R0,#1
400098 4000A9            [2] r1 @ r2 !              [1] MOV R2,R1
                         [ ] `: line90`             [ ] LINE90:
4000AA                   [1] r2 dec                 [1] SUBS R2,R2,#1
400285                   [1] `line40` jz            [3] BEQ LINE40
                         [ ]                        [?] LDR R7,[SP,R2,LSL #2]
4000B8 4000A88 DB 4000C9 [4] r6 @ r2 @ @ - dup r7 ! [1] SUBS R7,R6,R7
400AB5                   [1] `line140` jz           [3] BEQ LINE140
4000C3                   [1] r7 abs                 [1] RSBMI R7,R7,#0
400098 4000A8 DD         [3] r1 @ r2 @ - -          [1] SUB R8,R1,R2
                         [ ]                        [1] CMP R7,R8
4006AF                   [1] `line90` jnz           [3] BNE LINE90
                         [ ] `: line140`            [ ] LINE140:
4000BA                   [1] r6 dec                 [1] SUBS R6,R6,#1
40058F                   [1] `line70` jnz           [3] BNE LINE70
40009A                   [1] r1 dec                 [1] SUBS R1,R1,#1
4000988 4000B9           [2] r1 @ @ r6 !            [?] LDR R6,[SP,R1,LSL #2]
400ABF                   [1] `line140` jnz          [3] BNE LINE140
                         [ ] `: line180`            [ ] LINE180:

, то видно еще несколько мест, где возможны оптимизации, например n @ ! для коротких адресов за такт или даже экзотика вроде n @ @ - dup или n @ - -, но, думаю, достаточно, ибо ARM уже повержен, причем на его поле в режиме его эмуляции

Кстати, если брать самый свежий 4-битный процессор, то даже в самом простом исполнении он уступает ARM в режиме его эмуляции в 5 с чем-то раз. С другой стороны, ARM при рисовании 3d-бродилки (по сути это режим эмуляции форт-процессора!) в свою очередь сам уступает форт-процессору в несколько раз. Ну а продвинутый форт-процессор без проблем догоняет ARM в режиме его эмуляции, обгоняя при этом в 10-20 и более раз при рисовании 3d-бродилки. Подозреваю, что хищные процессоры уделают ARM одной левой

Кстати, последний суррогатный процессор из теста n-queens при частоте 50MHz выдает меандр 7.14MHz на тесте blink

Код:

:: begin (( ;
:: again )) ;
:: GPIO 0x8000 ;
begin
   0 GPIO !
   1 GPIO !
again

Total Vacuum

KPG писал(а):

Стандартный Cи тест Coremark

Надо будет как-нибудь собраться и написать свой транслятор си-в-форт, чтобы на моем процессоре си-шные тесты гонять

Кстати, подумалось, что и c 3-битными командами (чтобы утрамбовать 6 команд в 18-битном слове ПЛИС) процессор вполне взлетит. Например, такой:

Код:

0 1 push @ ! jz nand -

Литералы набиваются при помощи команды push, за которой следует серия команд 0/1, которые дописывают справа нолик или единичку в двоичное представление вершины стека. Стек возвратов делается программно на базе массива. Стековые манипуляции - через временные переменные в сегменте данных. Такой своеобразный стековый brainfuck получается.

Ну или чуть более продвинутое:

Код:

call ret word @ ! jz nand -

Здесь полноценные call/ret, а word переключает процессор в режим ввода литералов на несколько тактов.
Но все это может иметь хоть какой-то смысл только в том случае, если реализация в части потребления ресурсов ПЛИС окажется в разы более компактной, чем для процессора с 4-битными командами, а иначе овчинка и далее по тексту

Если получится компактное, тогда можно будет втиснуть процессор туда, где места почти не осталось. Ну или кучу ядер в ПЛИС запихнуть, особенно если умножения в системе команд не будет.
Ну а по хорошему надо бы уже процессор с 6-битными командами выкатывать: даже в простом варианте без акселератора (несколько команд за такт) должен не сильно уступать раскочегаренному процессору с 4-битными командами.

KPG

Total Vacuum писал(а):

Надо будет как-нибудь собраться и написать свой транслятор си-в-форт, чтобы на моем процессоре си-шные тесты гонять

Можно оттолкнуться от ранеее уже "сделанных" вариантов (и в рамках обсуждения на местном форуме c LCC -> Forth) или появишихся оригинальных как СС64 и/или вроде в DuskOS или задействоваать библиотеки с оптимизациями подобные LibJit.

P.S. Из топика Заказ собственных микросхем через TinyTapeout кто то заказал и микросхему своего проекта с RayCasting

https://github.com/algofoogle/tt04-raybox-zero
https://github.com/algofoogle/raybox-zero

При желании, вероятно возможно, и заказать свой Форт процессор в кремнии на исполнение в следующий TT05

Total Vacuum

KPG писал(а):

Можно оттолкнуться от ранеее уже "сделанных" вариантов (и в рамках обсуждения на местном форуме c LCC -> Forth) или появишихся оригинальных как СС64 и/или вроде в DuskOS

Мне как-то не попадались трансляторы си-в-форт. Ну или просто плохо искал

Да в любом случае проще свой транслятор написать, чем в чужом разбираться. Уже сейчас простые примеры типа факториала компилируются в uf \ micro forth \ (при желании и в классический форт тривиально оттранслируются) и работают, нужно лишь усилие, чтобы заставить себя довести до ума. А кроме того, любой уважающий себя компилятор должен уметь компилировать сам себя, поэтому компилятор си должен быть написан на си (я пока сам себя не компилирую, поэтому временно на tcc делаю), а duskos и cc64 вроде на форте написаны, если я правильно путаю.

tinytapeout - классная задумка, но я до такого не дорос еще

Hishnik

Total Vacuum писал(а):

tinytapeout - классная задумка, но я до такого не дорос еще

ПЛИС все-таки лучше. Tinytapeout слишком маленький, просто чрезмерно. Одно название "микросхема", а по сути схема на дискретных компонентах не так уж сильно будет отличаться - тоже кремний.

Total Vacuum

Ну так и форт-процессор в идеале вроде как не гигантский...

Собственно, небольшая проба пера с трансляцией си-в-форт.
Например, такой код

Код:

void emit ( char c ) ;
void type ( char * s ) ;

int i ;

struct node {
   char n ;
   struct node * next ;
} * list , nodes [ 256 ] ;

void main ( ) {
   for ( i = 0 ; i < 256 ; i = i + 1 ) nodes [ i ] . n = i ;

   nodes [ 'l' ] . next = & nodes [ 'i' ] ;
   nodes [ 'i' ] . next = & nodes [ 's' ] ;
   nodes [ 's' ] . next = & nodes [ 't' ] ;
   nodes [ 't' ] . next = 0 ;

   list = & nodes [ 'l' ] ;

   while ( list ) {
      emit ( list -> n ) ;
      type ( "->" ) ;
      list = list -> next ;
   }

   type ( "NULL" ) ;
}

превращается в такое (форматирование сделано вручную):

Код:

create i 1 cells allot
create list 1 cells allot
create nodes 512 cells allot

: main
   i 0 over ! @ drop begin i @ 256 < while
      nodes i @ 16 * + 0 + i @ over c! c@ drop
   i i @ 1 + over ! @ drop repeat

   nodes 'l' 16 * + 8 + nodes 'i' 16 * + over ! @ drop
   nodes 'i' 16 * + 8 + nodes 's' 16 * + over ! @ drop
   nodes 's' 16 * + 8 + nodes 't' 16 * + over ! @ drop
   nodes 't' 16 * + 8 + 0 over ! @ drop

   list nodes 'l' 16 * + over ! @ drop

   begin list @ while
      list @ 0 + c@ emit
      s" ->" type
      list list @ 8 + @ over ! @ drop
   repeat

   s" NULL" type
;
main

выводит:

Код:

l->i->s->t->NULL

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

Код:

create i 1 cells allot
create list 1 cells allot
create nodes 512 cells allot

: main
   0 i ! begin i @ 256 < while
      i @ nodes i @ 16 * + c!
   i @ 1 + i ! repeat

   nodes 'i' 16 * + nodes 'l' 16 * + 8 + !
   nodes 's' 16 * + nodes 'i' 16 * + 8 + !
   nodes 't' 16 * + nodes 's' 16 * + 8 + !
   0                nodes 't' 16 * + 8 + !

   nodes 'l' 16 * + list !

   begin list @ while
      list @ c@ emit
      s" ->" type
      list @ 8 + @ list !
   repeat

   s" NULL" type
;

main

Далее, если надо уменьшить размер или повысить читаемость кода, можно обыграть:

Код:

: nodes[i] 16 * nodes + ;
: .n ;
: .next 8 + ;
: ->n @ .n ;
: ->next @ .next ;

и т.д. и т.п.

Ну или, допустим, для факториала

Код:

void recurse ( ) ;
void cr ( ) ;
void emit ( char c ) ;

int fac ( char n ) {
   if ( n ) return n * recurse ( n - 1 ) ; else return 1 ;
}

int n , r ;

void main ( ) {
   n = 6 ; while ( n ) {
      n = n - 1 ;
      r = fac ( n ) ;
      while ( r ) { emit ( '.' ) ; r = r - 1 ; }
      cr ( ) ;
   }
}

получаем

Код:

: fac 0 pick if 0 pick 1 pick 1 - recurse * nip exit else 1 nip exit then ;
create n 1 cells allot
create r 1 cells allot
: main
   n 6 over ! @ drop begin n @ while
      n n @ 1 - over ! @ drop
      r n @ fac over ! @ drop
      begin r @ while '.' emit r r @ 1 - over ! @ drop repeat
      cr
   repeat
;
main

, которое после пары ручных правок превращается в

Код:

: fac dup if dup dup 1 - recurse * else 1 then nip ;
create n 1 cells allot
create r 1 cells allot
: main
   6 n ! begin n @ while
      n @ 1 - n !
      n @ fac r !
      begin r @ while '.' emit r @ 1 - r ! repeat
      cr
   repeat
;
main

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

Так что будет и под мой форт-процессор простенький компилятор си.

KPG

Total Vacuum писал(а):

Собственно, небольшая проба пера с трансляцией си-в-форт..

А, чем "плох" вариант испльзования Форт для для трансляции Си?
Могу скинуть свой вариант прототипа LCC -> SPf4 (делался на основе C2Forth on Mpe Ltd с их сайта)
и вариант от Михаила. (он преобразовывал LCC фронт-end в код SPF4), у меня LCC от Си (сборка на PellesC),
а библиотеки (stdlib, stdio ...) уже на SPF4 (топик есть на местном форуме)

Total Vacuum писал(а):

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

Так что будет и под мой форт-процессор простенький компилятор си.

Да, тоже столкнулся, что и Макро-оптимизатор в SPF4 уже не справляется с оптимизацией полученного кода SPF4.
На VFX Forth не проверял - может там лучше это получается.
А, работу макро-оптимизатора в SPF4, вероятно, может объяснить только Михаил.

Был ещё интересный проект F-- для использования Форт и Си совместно.

P.S. А, вообще, более интересен вариант транспиляции Форт в Си.
В этом направлении тоже существуют некоторые разработки, начиная от Timbre где Форт код по правилам на
Форт подобном языке преобразуется в Си.

Я тут немного "увлёкся" сборкой Linux Puppy (Xenial) с варианта использования собирания GLibc-2.33 из исходников для запуска,
В этом топике сообщения,
но похоже без сборки Xorg (и возможно ещё чего либо) этот вариант не запустить.
Сейчас думаю как запустить вентилятор в буке, чтобы при нагрузке бук можно было использовать.

Total Vacuum

KPG писал(а):

А, чем "плох" вариант испльзования Форт для для трансляции Си?
Могу скинуть свой вариант прототипа LCC -> SPf4 (делался на основе C2Forth on Mpe Ltd с их сайта)
и вариант от Михаила. (он преобразовывал LCC фронт-end в код SPF4), у меня LCC от Си (сборка на PellesC),
а библиотеки (stdlib, stdio ...) уже на SPF4 (топик есть на местном форуме)

Да я вроде не говорил, что "плох"

И тем не менее, компилятор Си лучше писать на Си, ведь проверка самокомпилируемости - это едва ли не лучший тест, проверяющий работоспособность. А во вторых, "использование Форт для трансляции Си" автоматически получится "на сдачу" (выхлоп-то на Форте!

) после того, как компилятор будет способен компировать сам себя

Понятно, что код еще придется шлифануть напильником, чтобы он читался и попроще был, но тем не менее...
Реализации Си-в-Форт на Форте было бы интересно посмотреть, здесь на форуме вроде была соответствующая тема, но ссылки там давно протухли.
Про с2forth от mpe я вроде читал когда-то давно, что-то такое припоминаю смутно, там у них кажись даже float не завезли, но могу ошибаться. И оригинальный LCC вроде смотрел, мне он показался каким-то громоздким.

Как сделать форт-процессор 2022

Кто сейчас на конференции