Forth
http://fforum.winglion.ru/

Нужны ли Форту нововведения?
http://fforum.winglion.ru/viewtopic.php?f=4&t=82		 Страница 3 из 4
Автор:  mOleg [ Вт авг 08, 2006 00:39 ]
Заголовок сообщения: 
Гм. Я тут подумал. Однопроходность компилятора в форте в принципе не обязательна в пределах одного определения и принципиально обязательна в пределах программы.
Автор:  Гость [ Вт авг 08, 2006 09:51 ]
Заголовок сообщения: 
oleg писал(а):
Гм. Я тут подумал. Однопроходность компилятора в форте в принципе не обязательна в пределах одного определения и принципиально обязательна в пределах программы.


На современных компьютерах однопроходовость компилятора не принципиальна.
Более важно наличие управляемого профилировщика кода.

P.S. Если использовать компилятор в контроллере, то там скорость загрузки
программы принципиальный фактор.
Так как Форт программы часто выполняются на регистровой архитектуре, то
необходимы компиляторы использующие их по полной:)
Автор:  chess [ Вт авг 08, 2006 15:25 ]
Заголовок сообщения: 
ArtemKAD писал(а):
В связи с тем, что х51 это "наследство тяжелого прошлого 80-й серии", то для этой задачи придется поступать методами тех времен - вести таблицу переноса - таблицу JMP-ов в которых при сдвиге кода надо менять метки.
В общем работа муторная и неблагодарная - результат никто не заметит ...

Наши компьютеры - это тоже наследство тяжелого прошлого 80-й серии, а форт-программы работают не на виртульных машинах и не на форт-машинах, а на этом "наследстве" и если компилятор сделает эту муторную работу, то результат будет заметен (управляющие конструкции с переходами вперед-очень частое явление). Я просто хочу сказать что без многопроходной компиляции такой оптимизации не достичь. Команды переходов внутри страницы памяти занимают меньше места в памяти, выполняются быстрее, чем команды перехода на полный адресный диапазон и поэтому имели право на существование.
Автор:  chess [ Вт авг 08, 2006 15:52 ]
Заголовок сообщения: 
oleg писал(а):
Гм. Я тут подумал. Однопроходность компилятора в форте в принципе не обязательна в пределах одного определения и принципиально обязательна в пределах программы.

Программа на форте в конечном итоге это главное слово, ну может и еще несколько слов для обработки прерываний. Если отдельные определения это процедуры, а главное слово просто набор из этих процедур то да. Если же среди определений попадаются инлайн-вставки и внутри главного слова куча ветвлений вперед, а это так и есть на 100% то без многопроходной компиляции не обойтись.
Автор:  ArtemKAD [ Вт авг 08, 2006 17:15 ]
Заголовок сообщения: 
chess писал(а):
и если компилятор сделает эту муторную работу, то результат будет заметен (управляющие конструкции с переходами вперед-очень частое явление).
Не частое - со всеми JMP-ами которые имеют относительную адресацию, а это насколько помню ВСЕ условные переходы, нет НИ МАЛЕЙШИХ проблем. Это стандартная "однопроходная" компиляция IF-THEN.
Проблема когда надо условный Jxx заменить на связку Jyy + LJMP или нечто подобное. Т.е. когда не хватает +-127 для условного перехода. А СКОЛЬКО у вас в программе мест с подобными "неожиданностями"? У меня даже с AVR-овскими +-63 чаще всего можно насчитать по пальцам одной руки. Причем проблема почти всегда решается перестановкой кода.
Тобишь оптимизация в подобном месте может быть вредна (руками я удачнее подправлю код), а частота появления сообщения "улетел за диапазон +127-128" настолько редкая (это не все ссылки вперед, а весьма малый их процент), что его исключение за счет автоматической вставки нужной пары комманд как я и сказал никто не оценит.
Автор:  ArtemKAD [ Вт авг 08, 2006 17:44 ]
Заголовок сообщения: 
Кстати ссылка почти в тему - http://www.forth.org.ru/~mlg/MoreBTng/ctlflow.htm
Автор:  вопрос [ Вт авг 08, 2006 20:50 ]
Заголовок сообщения: 
Кгда я познакомился с архитектурой х86 меня дико удивило, почему стеки и очереди не реализованы в железе (хоть по паре), а уж 4 такта на pop - шок.
Автор:  mOleg [ Ср авг 09, 2006 05:09 ]
Заголовок сообщения: 
Mihail писал(а):
Конструкция IF .... THEN
возможные варианты реализации ветвления if then в зависимости от величины кода между if и then и места этого куска в ROM
1. fif ?a!=0(.) lj(then) .|-----then
2. fif ?a!=0(.) aj(then).|-----then
3. fif ?a=0(then)|------------then
где fif - подпрограмма - заносит в аккумулятор False или True если на стеке 0 или не 0
?a!=0, ?a=0, lj, aj соответственно команды jnz, jz, ljmp, ajmp,
а теперь покажите как за один проход скомпилировать минимальный по объему и максимальный по быстродействию код и еще учтите, что эта конструкция будет вложена в несколько таких же конструкций


Долго не мог сообразить, чем мне не нравится утверждение. А вот сейчас дошло!
Я бы категарически запретил писать на форте слова длиннее 256 байт ( для 86 архитектуры)
а так же запретил бы вложенные циклы DO LOOP принудительно
и более чем 3 условных конструкции на одно слово!
Иначе программы на форте получаются уродливые и страшные!
Так что длинные переходы внутри слова не нужны. А оптимизировать переходы между словами не обязательно ( можно и динными обойтись ).
Автор:  chess [ Ср авг 09, 2006 08:48 ]
Заголовок сообщения: 
ArtemKAD писал(а):
Кстати ссылка почти в тему - http://www.forth.org.ru/~mlg/MoreBTng/ctlflow.htm

Эта ссылка показывает как предлагается реализовывать структуры управления, например:
Цитата оттуда:
Переходы вперед порождаются в два приема:
сначала порождается команда перехода по неуказанному адресу назначения, при этом вырабатывается значение orig (origin — исходная точка), содержащее информацию о недостроенном переходе вперед, в том числе адрес команды перехода;
когда адрес назначения становится известен, значение orig используется для записи адреса назначения в команду перехода.
В том то и дело, что команда перехода здесь понимается однозначно [код команды] [адрес перехода], как фиксированное количество байт, на самом деле количество байт команды перехода зависит от типа этой команды
(тип команды - относительный переход, абсолютный переход внутри страницы памяти, абсолютный переход во всем адресном пространстве) и сначала породить команду перехода по неуказанному адресу не удается, так не зная этот адрес мы не знаем и тип команды перехода. Решением в лоб является использование одного типа команд перехода (унивесального), который может разрешить любую ссылку вперед(это абсолютный переход во всем адресном пространстве). Это абсолютно неоптимально, так как, во-первых увеличивает размер кода, во-вторых вносит замедление исполнения.
Автор:  ArtemKAD [ Ср авг 09, 2006 12:33 ]
Заголовок сообщения: 
chess писал(а):
на самом деле количество байт команды перехода зависит от типа этой команды
(тип команды - относительный переход, абсолютный переход внутри страницы памяти, абсолютный переход во всем адресном пространстве) и сначала породить команду перехода по неуказанному адресу не удается, так не зная этот адрес мы не знаем и тип команды перехода.

По умолчанию принимаешь "короткий переход". Если это окажется не верно, выдается "далеко улетел". А далее руцями в программе либо переставляешь код (для того, что-бы попал в +-127) либо ставишь длинный переход (вместо C_IF ставишь C_IF_L).

Ведь чай не на БАСИК-е пишешь, и не совсем чайник раз уже с МК знаком :? .
Автор:  Mihail [ Ср авг 09, 2006 12:44 ]
Заголовок сообщения: 
ArtemKAD писал(а):
По умолчанию принимаешь "короткий переход". Если это окажется не верно, выдается "далеко улетел". А далее руцями в программе либо переставляешь код (для того, что-бы попал в +-127) либо ставишь длинный переход (вместо C_IF ставишь C_IF_L).


Раньше, я так и делал.
По моему, из примера
http://fforum.winglion.ru/viewtopic.php ... ight=#2002
видно, что мой оптимизатор эту задачу решает.
Автор:  ArtemKAD [ Ср авг 09, 2006 12:55 ]
Заголовок сообщения: 
Кстати, тут одна мысля только что пришла, для любителей БАСИК-а. Можно завести глобальный флаг модификации C_IF по которому подобная комманда компилирует длинный переход и сбрасывает этот флаг. А флаг у нас будет выставлять THEN при ошибке "далеко улетел". Кроме этого THEN вернет в файле и в целевом коде точки компиляции в место перед C_IF (точка передается точно так-же в стеке вместе с orig) .
Автор:  WingLion [ Ср авг 09, 2006 13:02 ]
Заголовок сообщения: 
Кстати, не совсем понятно (точнее совсем непонятно), почему это Форт запрещает многопроходную компиляцию?

Форт может все! (с)... - это аксиома.

Я бы, если бы мне понадобилось править джампы в исходниках, сделал бы это просто самим фортом.
Компилит форт исходник, обнаруживает джамп, который надо удлиннить, возвращется к исходнику и прямо в файл исходника вставляет JP вместо JR (применительно к Z80 сие).

И все! Отработал, сообшил, что исходник подправлен - требуется перекомпиляция, программист посмотрел, что там поменялось (если захотел смотреть) и запустил перекомпиляцию... Или автоматом оно само пошло!
Автор:  chess [ Ср авг 09, 2006 13:37 ]
Заголовок сообщения: 
ArtemKAD писал(а):
далее руцями в программе

Живем в век всеобщей автоматизации а все руцями :lol:
Автор:  ArtemKAD [ Ср авг 09, 2006 14:25 ]
Заголовок сообщения: 
chess писал(а):
Живем в век всеобщей автоматизации а все руцями

Не просто "руцями". Это замена достаточно слабой оптимизации кода (все равно код растет!) на оптимизацию алгоритма (позволяет обойтись вообще без роста).
Страница 3 из 4 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/