Язык Форт для ZX Spectrum

[Lethargeek]

Я согласен, прямой шитый код иногда может оказаться быстрей подпрограммного. Это когда NEXT сразу передаёт управление на следующее слово одной асмовской командой, такой случай описан у Черезова (каждется?) по мере развития его SP-Forth. Он экспериментировал и пробовал разные виды шитого кода, и версия с прямым борола по скорости подпрограммный. Но это на процессоре x86.

на z80 тоже есть одна такая асмовская команда - ret
правда, именно для форта применить сложно, оба стека надо делать программными
этот трюк больше для специфического шитого кода (динамическая генерация например)

насчёт (псевдо)фортокомпилятора для z80 у меня была такая задумка
стек параметров - аппаратный стек, причём верхнее число храним в регистре hl
стек возвратов - как-нибудь программно организуем, вызов относительно медленный
то есть схема ради скорости выполнения длинных цепочек примитивов прежде всего
по возможности примитивы не вызывать, а вставлять короткий код напрямую
только процедуры и сложные и длинные примитивы делать через call
(и возможно, в обрамлении вспомогательных коротких команд)
вызываемая процедура с адресом возврата в СП будет разбираться сама

то есть твой пример:

2 dup + .

компилируется в:

push hl: ld hl,2: push hl: pop de: add hl,de: call DOT - без оптимизации
push hl: ld hl,4: call DOT - c максимальной оптимизацией

а еще хороший оптимизатор сможет верхнее число держать не в hl, а как там по ходу дела получится

- - - Добавлено - - -

Форт хорош тем, что позволяет создавать легко макро-языки.

притом в диалоговом режиме интерпретатора при скорости, больше характерной для компиляторов

- - - Добавлено - - -

я по этой книжке врубался в форт:
http://publ.lib.ru/ARCHIVES/S/SEMENO...nov_Yu.A..html
там есть даже исходники простого интерпретатора для пц

[Oleg N. Cher]

на z80 тоже есть одна такая асмовская команда - ret

Да, сам думал о таком её применении.
Но увы, тогда придётся отказаться от прерываний и работать всегда только в режиме DI, иначе первое же прерывание испортит байт-код.

Так что указателем на программный код быть, видимо, регистру IX:

LD   L,(IX+0)
INC  IX
LD   H,(IX+0)
INC  IX
JP   (HL)

В HL ZX Forth оба стека - и возвратов, и операндов - аппаратные. Там есть слово для переключения стеков, если правильно помню, STKSWAP. При этом переключение стеков относительно медленное - адрес неактивного стека хранится в переменной.

А можно адрес стека операций хранить в IX, а стека возврата - в IY.

[Lethargeek]

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

необязательно, сам код может быть завязан на прерывания через "yield"

Так что указателем на программный код быть, видимо, регистру IX:

чем тебе PC не нравится в этой роли?

В HL ZX Forth оба стека - и возвратов, и операндов - аппаратные. Там есть слово для переключения стеков, если правильно помню, STKSWAP. При этом переключение стеков относительно медленное - адрес неактивного стека хранится в переменной.

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

А можно адрес стека операций хранить в IX, а стека возврата - в IY.

если целью ставить (при неплохой компактности) максимальное быстродействие, лучше вовсе избегать операций со стеком возвратов
так, если call-процедура не вызывает другие процедуры сама, можно сделать что-то наподобие pop ix на входе jp(ix) в конце
или как-нибудь еще по контексту

[Raydac]

сделай кросс компилятор forth а-ля http://forth.ru/smal32.html и с поддержкой его команд и все будут рады

[Oleg N. Cher]

необязательно, сам код может быть завязан на прерывания через "yield"

А это как?

чем тебе PC не нравится в этой роли?

PC - как указатель на шитый код? :-)

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

Вот именно, что как раз оба аппаратные. Потому что активный стек адресуется через SP, и работа с ними происходит с помощью команд PUSH/POP, в переменной только хранится адрес другого стека и меняется местами с SP при вызове слова STKSWAP.

так, если call-процедура не вызывает другие процедуры сама, можно сделать что-то наподобие pop ix на входе jp(ix) в конце
или как-нибудь еще по контексту

Ну да, что-то такое можно придумать.

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

Легко сделать примитивненький транслятор Форта с банальным шитым кодом, на основе любого из готовых Фортов для Z80/i8080, но вряд ли на нём сразу кинутся писать игры и всё остальное. Аудитория будет маловата. А в принципе и с хорошим оптимизатором он, сдаётся мне, мало кого заинтересует...

[Shiny]

насчет реализации ret: не знаю, уместно или нет, но пришлось использовать другое решение:

я адаптировал для Amstrad CPC музыкальный плеер. Необходимо было вызывать процедуру записи данных в AY. Но плеер использовал стек, поэтому call writeAY не прокатил бы.
Вышел вот такой изврат:

 LD BC,NN
 LD IX,BACK1
 JP WRITEAY
BACK1:

...
WRITEAY:
;несколько действий
 JP(IX)

[Advertiser]

[Lethargeek]

А это как?

фортокод вызывается из обработчика (чисто ради подстраховки после di)
делает что может в кадре успеть (предварительно по тактам прикинуть грубо)
после спецкомандой запоминает текущий указатель в памяти и ei:halt

PC - как указатель на шитый код? :-)

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

Вот именно, что как раз оба аппаратные.

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

Мне кажется, сложная оптимизация Форта, о которой ты говорил сейчас и ранее, это и есть самый камень преткновения. Здесь всё очень сложно реализовать.

совсем сложную с наскока необязательно, для начала "склеивать" 2-3 фортопримитива последних намного проще

Но я бы пошёл ещё дальше - ушёл от стека вообще.

но тогда и из этой темы уйти придётся

[svofski]

Советую обратить внимание на DX-Forth для 8080: http://dxforth.netbay.com.au/
В принципе он для CP/M, но не думаю, что перенести его на другую платформу окажется чем-то неподъемным. Это не какая-то странная древняя система, а вполне современный Форт не хуже gforth. Код открыт, последняя версия датирована октябрем 2016 года. Умеет генерировать запускаемые файлы, при этом оптимизируя словарь. Автор охотно общается и дает крайне полезные советы. Огромный ему респект.

[Oleg N. Cher]

фортокод вызывается из обработчика (чисто ради подстраховки после di) делает что может в кадре успеть (предварительно по тактам прикинуть грубо) после спецкомандой запоминает текущий указатель в памяти и ei:halt

Интересная идея, надо обдумать.

но тогда и из этой темы уйти придётся

Ну зачем же. Говорим Форт - подразумеваем стек? ;-) А я там дал примерчик как можно на регистрах работать. И мне жаль, что никто до сих пор не ушёл от стека. Идея Форт-системы - превосходна. Так просто порождать новые проблемно-ориентированные языки. Но все они остаются опасными, потому что есть ! , @ HERE и ALLOT. И вот то, что остались на древних примитивах и выворачивании с их помощью мозга при кодинге - плохо, я считаю. Развивать Форт-идеологию нужно именно в сторону ухода от низкоуровневых примитивов. Никто не говорит, чтобы от них избавиться совсем. Но, по крайней мере, уменьшить их использование до задач низкого уровня (примерно как псевдомодуль SYSTEM в Обероне).

[Lethargeek]

Ну зачем же. Говорим Форт - подразумеваем стек?

именно, два стека - основной признак (а вот шитый код как раз и необязателен, что форт-компиляторы демонстрируют)

А я там дал примерчик как можно на регистрах работать.

ну и работай, только свой язык придумай, при чём тут форт

И мне жаль, что никто до сих пор не ушёл от стека.

как никто, а бейсик-вильнюс на шитом коде?

Идея Форт-системы - превосходна. Так просто порождать новые проблемно-ориентированные языки. Но все они остаются опасными, потому что есть ! , @ HERE и ALLOT.

а при чём тут стековость языка? есть же современный безопасный стековый Factor

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

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