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 писал(а): далее руцями в программе
Живем в век всеобщей автоматизации а все руцями |
Автор: | ArtemKAD [ Ср авг 09, 2006 14:25 ] |
Заголовок сообщения: | |
chess писал(а): Живем в век всеобщей автоматизации а все руцями
Не просто "руцями". Это замена достаточно слабой оптимизации кода (все равно код растет!) на оптимизацию алгоритма (позволяет обойтись вообще без роста). |
Страница 3 из 4 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |