Forth
http://fforum.winglion.ru/

Как разработать кросс-компилятор Форта для микроконтроллеров
http://fforum.winglion.ru/viewtopic.php?f=39&t=2271
Страница 2 из 4

Автор:  вопрос [ Сб сен 05, 2009 21:00 ]
Заголовок сообщения: 

Да, хороший текст :)
Цитата:
Компиляция - конкатенативная (за исключением вялотекущих замечаний Михаила, что он может написать любой оптимизатор, вот только пока получаются полуфабрикаты), а значит, программа состоит преимущественно из вызовов подпрограмм.

этот полуфабрикат даёт в отдельном случае до 3-5 кратного прироста производительности

Автор:  Hishnik [ Сб сен 05, 2009 22:03 ]
Заголовок сообщения: 

вопрос писал(а):
этот полуфабрикат даёт в отдельном случае до 3-5 кратного прироста производительности

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

Автор:  вопрос [ Сб сен 05, 2009 23:20 ]
Заголовок сообщения: 

Хищник писал(а):
вопрос писал(а):
этот полуфабрикат даёт в отдельном случае до 3-5 кратного прироста производительности

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

За это спасибо и я думаю, что интересно всем.
Насчёт случаев - я не могу ничего сказать точно, действительно, разница между случаями велика и уступает С++ . Я тоже удивился, не может, думаю, быть 5-кратной разницы, может неправильно сравнивал, но неоднократно

Автор:  Hishnik [ Сб сен 05, 2009 23:48 ]
Заголовок сообщения: 

вопрос писал(а):
Насчёт случаев - я не могу ничего сказать точно, действительно, разница между случаями велика и уступает С++ . Я тоже удивился, не может, думаю, быть 5-кратной разницы, может неправильно сравнивал, но неоднократно

Я не пытаюсь сейчас говорить о конкретном оптимизаторе. Я просто предостерегаю от попыток уйти в мечтания о супернаворотах, которые когда-нибудь в будущем превратят планируемый кросс-транслятор в чудо из чудес. Данное предостережение актуально для любых продуктов на базе Форта (да и других редких языков). Правильно спланировать предполагаемые результаты я считаю не менее важным, чем заниматься собственно техникой программирования, потому что вполне можно прочитать вот это все и сказать "да-да, конечно, добавляю в свою копилку как-бы-мыслей, и продолжаю их как-бы-обдумывать, ура Форту, а поскольку я его знаю, я - крутой программист". А это будет означать, что время на чтение потрачено впустую.

Автор:  mOleg [ Вс сен 06, 2009 00:11 ]
Заголовок сообщения: 

да, по поводу номеров, имхо, мне больше нравится префиксный вариант:

h: FFDC d: 1239
и т.д.
он же повзоляет достаточно легко ввести контроль разрядности чисел, а так же контроль адресов при необходимости.

ну и словари никто не отменял 8) в некоторых системах.
а еще в том же СПФ можно использовать NOTFOUND , и числа писать, к прмеру в виде t123452 thFD4

вобщем числа не должны вызывать проблем.

Автор:  Hishnik [ Вс сен 06, 2009 00:18 ]
Заголовок сообщения: 

mOleg писал(а):
да, по поводу номеров, имхо, мне больше нравится префиксный вариант:

h: FFDC d: 1239
и т.д.
он же повзоляет достаточно легко ввести контроль разрядности чисел, а так же контроль адресов при необходимости.

Да, действительно, это тоже можно использовать.

mOleg писал(а):
вобщем числа не должны вызывать проблем.

Под проблемой я имел в виду только вынужденное отличие от стандартной для Форта формы записи. Получается, что если мы берем некий "усредненный" транслятор для PC, то не так-то просто передать числа в МК. Хотя, разумеется, эта проблема имеет целый ряд решений.

Автор:  chess [ Вс сен 06, 2009 09:51 ]
Заголовок сообщения: 

Хищник писал(а):
Под проблемой я имел в виду только вынужденное отличие от стандартной для Форта формы записи. Получается, что если мы берем некий "усредненный" транслятор для PC, то не так-то просто передать числа в МК. Хотя, разумеется, эта проблема имеет целый ряд решений.

Форма представления чисел для МК в тексте программ может быть и стандартной.
Дело в том, что сами по себе числовые литералы не нужны. Они используются
внутри процедур. Сами процедуры-слова форта для МК могут включать обработчик для нестандартной интерпретации числовых литералов. Опять решают не сами данные(их представление), а то как(чем) они будут обработаны(форт - бестиповый язык).

Автор:  Hishnik [ Вс сен 06, 2009 15:18 ]
Заголовок сообщения: 

chess писал(а):
Форма представления чисел для МК в тексте программ может быть и стандартной.
Дело в том, что сами по себе числовые литералы не нужны. Они используются
внутри процедур. Сами процедуры-слова форта для МК могут включать обработчик для нестандартной интерпретации числовых литералов. Опять решают не сами данные(их представление), а то как(чем) они будут обработаны(форт - бестиповый язык).

Вчитываемся, вчитываемся :) Замечание оказалось совершенно не в тему.

Автор:  chess [ Пн сен 07, 2009 12:44 ]
Заголовок сообщения: 

Ну почему не в тему, вот вчитываемся вот в это:
Хищник писал(а):
Некрасиво, зато дешево и сердито.



Код:function test

2 # 2 # +

end-function

В нашем примере слово # (это слово не Форт-МК, а Форта в нашем кросс-компиляторе) будет компилировать код, который поместит число на стек МК.


Смысл того, что я писал сводится к тому, что
запись 2 # 2 # + сводится к записи 2 2 +,
а все преобразования делаются внутри слова + .

Автор:  Hishnik [ Пн сен 07, 2009 18:54 ]
Заголовок сообщения: 

chess писал(а):
Смысл того, что я писал сводится к тому, что
запись 2 # 2 # + сводится к записи 2 2 +,
а все преобразования делаются внутри слова + .

Ну и как это организовать на практике? Заставлять + принудительно забирать со стека инструментального Форта два числа? :) И каждому слову забирать требуемое число параметров? Элементарный пример

Код:
get-first get-second +


Оба слова положили по числу. Но + все равно полезет в инструментальный транслятор за аргументами?

Автор:  chess [ Вт сен 08, 2009 11:53 ]
Заголовок сообщения: 

Хищник писал(а):
Ну и как это организовать на практике?

Достаточно просто.
Код:
: inv-iS  DEPTH 0 ?DO I ROLL LOOP ;     \ инверсия инструментального стека
: iS>tS   inv-iS DEPTH 0 ?DO # LOOP ;   \ перенос чисел с инструментального стека на целевой

: s:  \ определение процедуры
CREATE t-adr ,                 \ t-adr - указатель на первый свободный байт целевого пространства кода
DOES>  iS>tS                   \ перенос чисел с инструментального стека на целевой
       lcall                   \ формирование кода вызова процедуры
;

При компиляции любой процедуры параметры с инструментального стека (если они там есть) "переносятся" на целевой стек.
Целевой код каждой процедуры работает с параметрами на целевом стеке.
PS. Примерно так я сделал в своем компиляторе.

Автор:  Hishnik [ Вт сен 08, 2009 20:25 ]
Заголовок сообщения: 

chess писал(а):
При компиляции любой процедуры параметры с инструментального стека (если они там есть) "переносятся" на целевой стек.
Целевой код каждой процедуры работает с параметрами на целевом стеке.

Это именно то решение, на проблематичность которого я и хотел обратить внимание. А с чего вдруг
1) Все числа инструментального стека должны попасть в целевой? А если у нас внизу лежит что-то еще?
2) Остается нерешенной проблема отказа от переноса, если числа на целевом стеке уже будут находиться в результате действий предыдущих слов.

Код:
get-first get-second +


Еще раз повторяю вопрос: + заберет два числа с инструментального стека? Даже несмотря на то, что забирать их не надо?

Автор:  chess [ Ср сен 09, 2009 07:54 ]
Заголовок сообщения: 

Хищник писал(а):
1) Все числа инструментального стека должны попасть в целевой? А если у нас внизу лежит что-то еще?

Ну один пример того, что на дне инструментального стека лежит что-то уже есть - там лежит адрес кода процедуры в целевом пространстве.
Этот момент легко обходится(уменьшением DEPTH на 1, или пересылкой адреса на стек возвратов).
Хищник писал(а):
2) Остается нерешенной проблема отказа от переноса, если числа на целевом стеке уже будут находиться в результате действий предыдущих слов.

Какой отказ. Перенос уже сделан. На инструментальном стеке ничего нет, значит на целевой ничего уже переноситься не будет.
Стек хоть и целевой, но по-прежнему остается глобальной структурой данных.
Вообщем вопросы типа А если у нас внизу лежит что-то еще? вопросы, на которые надо сначала ответить себе самому.
Хищник писал(а):
Еще раз повторяю вопрос: + заберет два числа с инструментального стека? Даже несмотря на то, что забирать их не надо?

В данном случае + ничего не заберет, так как инструментальный стек пуст.
Если бы было
Код:
5 6 get-first get-second +

то + взял бы 5 6 с инструментального стека заполнил целевую память кодом
Код:
положить числа 5 и 6 на целевой стек
, но при исполнении сложил бы числа, оставленные
словами get-first get-second.
Да еще для конкретности как выглядит определение самого + ( 16-разрядный компилятор для MCS-51)
Код:
s: +   \ n1 n2 --> n1+n2
a=@r0  r0++  a+dpl  dpl=a
a=@r0  r0++  ac+dph dph=a
ret

Автор:  chess [ Ср сен 09, 2009 08:48 ]
Заголовок сообщения: 

chess писал(а):
Если бы было

Код:5 6 get-first get-second +

то + взял бы 5 6 с инструментального стека заполнил целевую память кодом Код:положить числа 5 и 6 на целевой стек, но при исполнении сложил бы числа, оставленные

словами get-first get-second.

Написал неправильно, на самом деле слово get-first снимет числа 5 6 с инструментального стека и положит их на целевой.

Автор:  Hishnik [ Ср сен 09, 2009 08:49 ]
Заголовок сообщения: 

chess писал(а):
Ну один пример того, что на дне инструментального стека лежит что-то уже есть - там лежит адрес кода процедуры в целевом пространстве.
Этот момент легко обходится(уменьшением DEPTH на 1, или пересылкой адреса на стек возвратов).

Это называется "создадим проблему, а потом начнем оптимизировать пути ее обхода" :))
chess писал(а):
Какой отказ. Перенос уже сделан.

Вот именно.

Код:
1 2 3 4 5 6 + - * AND OR

На 6 операндов вполне корректные 5 операций, т.е. выражение вообще корректно. Но каждое из 5 слов заберет с инструментального стека по 2 операнда! То есть уже AND не заберет ничего.
chess писал(а):
Вообщем вопросы типа А если у нас внизу лежит что-то еще? вопросы, на которые надо сначала ответить себе самому.

А чего тут отвечать-то? Я хочу скомпилировать код для МК в соответствии с правилами Форта. Если особенности (читай - глюки) инструментального транслятора не дают мне это сделать - это плохой транслятор, и плохой кросс-компилятор на нем. Как обойти это ограничение - я написал. Конечно, если хочется потом помучаться, вылавливая глюки, можно ответить "да-да, но ведь можно еще и так", и продолжать писать некорректно работающий код.
chess писал(а):
Если бы было
Код:
5 6 get-first get-second +

то + взял бы 5 6 с инструментального стека заполнил целевую память кодом Код:
положить числа 5 и 6 на целевой стек
, но при исполнении сложил бы числа, оставленные
словами get-first get-second.

То есть код для МК был бы скомпилирован неправильно. Таким образом, подобное решение зависит от наличия непосредственных значений на стеке инструментального транслятора в процессе кросс-компиляции, и работающим считаться не может.

Страница 2 из 4 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/