Решил я начать такой топик, копаясь в ядре СПФ.

: ?IMMEDIATE ( NFA -> F ) NAME>F C@ &IMMEDIATE AND ;
на первый взгляд все хорошо. А на второй не очень, так как значение, выдаваемое этим словом может меняться в зависимости от константы &IMMEDIATE и это слово нельзя в дальнейшем использовать как флаг ( то есть оно не равно -1 ) - это не баг - это фича, на которую можно неприятно натолкнуться.
То же самое и с
: ?VOC ( NFA -> F ) NAME>F C@ &VOC AND ;

для исправления ситуации нужно в конец каждого определения добавить 0<>

Дальше, вводит в замешательство некоторое кол-во необоснованно обосемблерных слов ( особенно при наличии оптимизатора)

NAME> , NAME>C , NAME>F , NAME>L
впрочем сюда можно отнести и CDR

так же смущает достаточно сложная организация словарной статьи:
чтобы перейти на предыдущее слово - нужно обойти имя, длинна поля которого не фиксирована 8(
Не то, чтобы слишком большие тормоза, но на фоне NAME>L в ассемблере смущает.

На этом сомнительные слова не кончаются 8(
Слово CREATED - вообще шедевр!! Зачем там столько понакручено вокруг выравнивания я так и не смог понять. Конечно не самое часто вызываемое слово - НО! Это-ж надо такого навертеть!

Еще некоторые правки:
: LATEST ( -> NFA ) CURRENT @ @ ;
стоит заменить на
: LATEST ( -> NFA ) GET-CURRENT @ ;

И еще, не вижу надобности писать SEARCH-WORDLIST1 на ассемблере. Скорости это сильно СПФ-ному поиску не добавит! Нужно либо делать хешированные словари или пользоваться надстройками QuickSWL.

Поиск же переписать так:

стоит так же ввести слово

так как переход СПФ на строки в формате "ADDR #" уже давно стоит считать завершенным!!!


[/code]

Чтобы это всё имело смысл - стоит писать в spf-dev.

Еще одной неприятной особенностью СПФ является постоянное дерганье перенной BASE.
Если вы станете серьезно копаться в нутрях этой системы, то обращайте пристальное на это внимание.
Так как перенос того или иного слова выше или ниже того места, где оно находится череват непонятными проблемами.

Ну и самой неприятной вещью для любителя разбираться в исходных текстах спф является оптимизатор.
Многи слова вообще не понятно как работают. Я смотрел в исходные тексты СПФ3 - там еще небыло оптимизатора, так вот там все выглядит достаточно просто и на много красивее 8( В новых релизах понятно далеко не все. Может кто-нибудь мне сможет объяснить, что же наварочано в слове ?BRANCH и какой в его основе лежит код???

а еще: не соответствие нотаций,
1. FILE-POSITION ( fileid -- ud ior ) возвращает на стек три значения а не два
2. REPOSITION-FILE ( ud fileid -- ior ) снимает со стека три значения а не два
3. RESIZE-FILE ( ud fileid -- ior ) снимает со стека три значения а не два
что я не правильно делаю ?

Канонический код генерируемый ?BRANCH можно получить так:


?SET SetJP SetOP просто отмечают текущую вершину кодофайла.
Единственное что может смутить это ???BR-OPT .
В файле заглушек он имеет вид:


В src\macroopt.f ???BR-OPT производит подъмену скомпилированного кода
в сочетании с модификацией переменной J_COD и заботой о сохранении флагов.
J_COD - содержит часть кода-команды, для формирования условного перехода.

ud - считается одним значением, хоть и двойной длинны

спасибо
значит просто был не прав,
можно пост убирать

Еще одно предложение для включения в СПФ, да и все друге форты.

ввести глобальную переменную PREFER и слово ALWAYS

: ALWAYS BASE @ PEFER ! ;l

в spf_init.f POOL-INIT и в spf_win_envir.f ERROR2 добавить

PREFER @ BASE !
это дает возможность устанавливать систему в заданное HEX DECIMAL OCT BIN - состояние и в случае ошибки из него не выпадать в десятичную систему. Очень удобно, когда щупаешь железяки - установился в HEX один раз и все



Я сравнивал код спф3( где еще небыло оптимизатора) и спф4. Так вот спф3 выглядит гораздо более понятно.
Может всетаки стоит вынести оптимизатор из кода ядра? Весит он очень много, столько же, сколько все остальное, в ядре из-за него много непонятного понаписано, кроме того оптимизатор по опят же непонятной для меня причине подключается 3и!!! раза для сборки новой версии спф. И подключается долго.

Можно для этой цели завести переменную PREFER, а слово ALWAYS
не ненужно. Во первых фрагмента
вполне достаточно, во вторых устанавливать PEFER будет требуется очень редко,
в третьих словом ALWAYS наверняка будут обзывать установку всяких режимов.



Мы это уже рассматривали.
1. Сделать версию СПФ без оптимизатора. Начиная с замены файла macroopt.F
на файл заглушек http://fpauk.narod.ru/optgag.f
2. Все сова ссылающиеся на слова из optgag.f сделать векторными

Других приемлемых вариантов пока не вижу.

это, конечно возможно, что будут называть, но пока что такого имени я не встречал.
во вторых я привык работать в 16 системе. И меня сильно напрягает каждый раз, после ошибок в консоли писать HEX.



Это только временное решение. Так как из-за оптимизатора текст СПФ не читаем.
Кстати нашел еще несколько несуразностей.
Вопервых из кода : proba NOOP 5 + ; оптимизатор выкинет NOOP, а именно с нопом этого он делать не должен, так как я могу захотеть туда что-нибудь другое записать, для того, чтобы поменять поведение слова. Именно NOOP не должен выкидываться из кода оптимизатором.
Еще один момент в spf_wordlist.f переменная LAST должна быть USER переменной, иначе СПФ многопоточную компиляцию не поддерживает! Это глюк.

Да, может всетаки подключать оптимизатор в самом конце?
И не подключать его два раза, а только один? Ведь оптимизатор уже есть в самом СПФе, на котором собирается новый релиз! А то слишком долго компилится СПФ.

И еще одна неприятность СПФ, слова HEADER, WORDLIST определяются по ходу сборки дважды!
Это значит, что любые изменения нужно делать в двух местах. Это плохо. Предлагаю вынести эти слова в отдельные файлы и при надобности подключать ( хот десять раз 8<) Собственно говоря я это уже сделал. Кстати, если интересно, могу послать результаты моей работы над СПФ - может найдешь часть из них разумными?

Кстати еще одно замечание,
ЕСЛИ ХОТИТЕ, ЧТОБЫ ПРОЕКТ СОБИРАЛСЯ В ДВА РАЗА БЫСТРЕЕ
пишите:
WARNING 0!
в СПФ ну очень тормозной поиск по словарю.
Правда еще один вариант, это не компилировать слова в базовый словарь, а раскидывать их по маленьким словарям.

Странные дела...
По идее, имхо, Форт просто не должен сам менять BASE при ошибках.
А если меняет, то надо это дело править...
Мне даже непонятно, зачем его менять... номер ошибки выводить десятичный, что ли?

на самом деле так делают почти все форты. Причина проста, можно после ошибки оказаться с совсем неприемлемой BASE. Это как раз таки нормально. Просто обычно не учитывается тот факт, какая система была. Я опробовал данный подход еще в Смал32 - оказалось, что очень удобно, когда щупаешь руками железо

Я обычно просто пользуюсь словами H. и DH. когда надо в хексе что-то смотреть (они и работают быстрее обычной точки).

А в самом Форте при необходимости вывести что-то в десятичной системе, сохраняю и восстанавливаю BASE примерно вот так: