Советы по написанию транслятора.

Я вот тут писать ФОРТ собрался под x86 BSD и вот хочу спросить. Решил что лучше будет сделать в таком шитом коде: поскольку под 32 бит архитектуру и слова выравнивать на границу 4 байта надобно, то можно использовать младшие два бита адреса под свои нужды, конкретно можно младший битиспользовать как определение типа слова(машинное или в шитом коде), посему интепретатор шитого кода будет проще и шустрее. Или может лучше по-другому сделать как-то?

>Я вот тут писать ФОРТ собрался под x86 BSD

А ты уверен, что это надо делать, вообще говоря?

См. FreshPorts — lang/forth

А если хочется руки приложить, то можно подключиться к проеку переложения SP-Forth под Linux и сделать такую штуку под BSD


http://wiki.forth.org.ru/SPF4%20%ED%E0%20Linux

Настолько ли сильная потеря? Анализ бита одна инструкция, переход на вариант машинное/немашинное и еще пара инструкций. Думается мне не так уж и много потеряю. 3-4 такта на машинное слово, 5-6 на обычное.

Написание- может быть и 2 недели. А отладка ...

Чего там отлаживать-то?:) Уже через две недели имел вполне рабочий форт. Ну может в каких-то малопользуемых словах и остались ошибки, но они все такие простые и отлаживались тут же, после написания. Вот ассемблер неделю писал, и потом еще дня три ловил баги. Ну ничего так, вполне все работало. Я ведь велосипед изобретал не только потому что не было никакого транслятора, но и потому что задачка несложная. 6 кб получился бинарник. Мало кода.

Ага. Ну тогда может пнешь в меня ссылкой на тему правильного построения трансляторов? Или может даже сам объяснишь?:) Я собственно именно за советом и пришел, пока еще не начал писать и не жалко отказываться от отдельных моментов затеи.:)

При традиционном шитом коде в слова вписываются прямо адреса полей слов, откуда их нужно запускать (CFA - Code Field Address). Для низкоуровневых слов это прямо ссылки на их код, для высокоуровневых - ссылки на пролог (пролог может быть как общим, что несколько снижает скорость, так и у каждого слова свой, что потребляет немного лишней памяти). Код каждого слова заканчивается инструкцией "NEXT", передающей управление следующему слову.

Традиционно, один из регистров резервируется под указатель слов, WP (Word Pointer) и он постоянно, как и процессорный IP, указывает на адрес следующего слова. Но на x86 архитектуре (в отличие от всевозможных DEC/68K/ARM/MIPS и т.п.) из-за её бедности (нет автоинкрементов при косвенной адресации и т.п.) проще хранить адрес последнего выполненного слова. Тогда процедура NEXT обычно выглядит в таком духе:

1. ; NEXT
2.     add eax, 4
3.     jmp [eax]

Легко видеть, кстати, что в любой x86 системе такая конструкция по тактам занимает места меньше, чем call/ret. Так что на вызове низкоуровневых слов Форт с шитым кодом обходит обычные подпрограммные вызовы классических ЯВУ. Но вот когда дело доходит до вызова высокоуровневых слов - там нужно сохранить текущий WP на стеке возвратов, загрузить новый, а в конце - вернуть WP. Тут начинается некоторый проигрышь.