минимальный форт-транслятор

Варнак

Хищник писал(а):

Понятие "ассемблер" используется в двух смыслах - и как машинный код, и как язык программирования, основанный на мнемониках для этого кода.

Бывает что и используется, но, когда мы говорим вот об этом:

Цитата:

... используются вставки вида: [ 0xC3 B, 0xD2 B, ]

- то удобнее эти смыслы разделять.

Hishnik

Варнак писал(а):

Бывает что и используется, но, когда мы говорим вот об этом:
Цитата:
... используются вставки вида: [ 0xC3 B, 0xD2 B, ]
- то удобнее эти смыслы разделять.

А зачем же разделять, если этому фрагменту мы можем поставить в соответствие взаимно однозначное слово Форта, и назвать его командой форт-ассемблера?

вопрос

Цитата:

Если Форт неспособен что-либо подгрузить, то это не Форт вообще.

речь идёт о минимальном форте, а способность подгрузить расценивается в отношении того, улучшает ли минимальность или ухудшает

Mihail

вопрос писал(а):

речь идёт о минимальном форте, а способность подгрузить расценивается в отношении того, улучшает ли минимальность или ухудшает

Вопрос сводится к тому, где находятся его компоненты: в базовом загрузочном модуле или
во внешней библиотеке. Принципиальной разницы не вижу. Для реализации Форт-системы
для другой платформы следует минимизировать количество примитивов. Далее, по
мере необходимости, для повышения быстродействия, можно заменит высокоуровневые
слова примитивами или применить оптимизатор.

idem

Чтобы не отвлекаться на формулировки, приведу цитату из БСЭ

Цитата:

АССЕМБЛЕР … Один из видов транслятора.

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

in4 писал(а):

Редактор при записи переводит внутренние структуры в это представление (у Мура оно хранится в блоках) и переводит в отображаемый вид при редактировании.

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

вопрос

Цитата:

Чтобы не отвлекаться на формулировки, приведу цитату из БСЭЦитата:
АССЕМБЛЕР … Один из видов транслятора.

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

Собственно, поскольку эту часть разговора начал я, то виноват я тут или прав - слово "ассемблерный" употреблялось в смысле, который заметил Хищник

Цитата:

Понятие "ассемблер" используется в двух смыслах - и как машинный код, и как язык программирования, основанный на мнемониках для этого кода.

Это и имелось ввиду - язык (или что-то ещё) непосредственно (без надстроек) отображающее структуру машинного кода

в этом смысле подгружаемый бинарник - тоже ассемблерный код (он не структурирован в шитый например)

in4

chess писал(а):

in4 писал(а):

Это уже есть, у ~ac-а b ~profit-а были наработки.

Что-то у них ничего подходящего не обнаружил.
У ~pinka есть кое-что(storage.f), но сходу не заработало.

~profit\lib\colorForth\cascaded.f писал(а):

Код:

\ Каскадные определения. Отделение словарных структур от кодофайла (хранилища).
...

это то, что я использовал.

что-то про словари есть в ~ac\lib\ns\ns.f

in4

idem писал(а):

in4 писал(а):

Редактор при записи переводит внутренние структуры в это представление (у Мура оно хранится в блоках) и переводит в отображаемый вид при редактировании.

Как мне кажется, это первый вариант для более детального рассмотрения.

А есть идеи?

У меня-то есть, и много, но пока не реализовано...

idem писал(а):

С другой стороны, это можно отнести к реализации ФВМ, потому что первое слово уже платформозависимо, но что-то в этом есть половинчатое.

Не совсем понял. Такая возможность может быть и платформонезависима.

Но платформонезависимость приводит к неэффективности. Реализации должны быть платформозависимы, если нужно использовать ресурсы систем по максимуму. Иначе -тривиальное решение- эмулятор старой платформы и под ним работа старой проги...

А что реально надо - это возможность удобными средствами обеспечивать помощь при создании и сопровождении нескольких похожих исходников (в т.ч. для разных платформ). Такого нигде не видел. Более того, встретился с мнением, что такое нельзя делать принципиально из-за стандартных технологий производства ПО (прогр. обеспечения). А ведь такое средство могло бы обеспечить работу с Форт-системами минимальных размеров для каждой из платформ...

А ведь бОльшая часть программы под разные платформы, по идее, должна быть одинакова, если сделана более-менее нормальная модель и слова более низкого уровня переписаны для новой платформы.

вопрос

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

Hishnik

Что мне вдруг подумалось - так это то, что объем обсуждения уже стал как бы не больше объема минимального форт-транслятора :shuffle;

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

idem

in4 писал(а):

Не совсем понял.

Я имел в виду, что первое слово(загрузочный модуль) уже должен быть скомпилирован в конкретной ОС, т.е. иметь определенный формат файла.

in4 писал(а):

А есть идеи? У меня-то есть, и много, но пока не реализовано...

Да проблема не в количестве идей, а в критериях их сортировки. Например, платформозависимость vs платформонезависимости )метр или килограмм). Аргумент для первого варианта – это возможность «использовать ресурсы систем по максимуму». Аргумент для второго – переносимость программ. И здесь решающим аргументом может быть количество функций отданных ФВМ.

mOleg

Хищник писал(а):

чем задача-то?

просто в обсуждении каждый стал говорить о чем-то своем, так сказав, забыв постановку задачи.

Речь идет о следующей ситуации. Есть некая новая платформа для которой, возможно, даже никаких программных инструментов.
Для нее нужно за минимальное время с минимальными усилиями создать Форт-систему, с которой в дальнейшем можно работать,
И, которая сама будет вполне самодостаточной (то есть должна позволять забыть о существовании любых внешних инструментов за ее пределами).
Поэтому есть следующие условия:
1) простота реализации (а значит, небольшое количество примитивов)
2) минимальный возможный размер (исходника)
3) полнота функциональности (то есть должна позволять штатными средствами реализовать любую конструкцию).

Задача вполне реальная,
и нужно по сути даже не саму форт-систему иметь,
а набор слов, которые нужно реализовать
и их стековые соглашения
и порядок их написания.

Все остальное: про ассемблер, про загрузчики форт-ядра (3-х стековый Форт) и что там было еще к задаче отношения не имеет.

Что касается данных ссылок в данной теме. Ссылка на eForth действительно близка (там всего ~30 примитивов), но сам eForth не минимален, в нем есть достаточно лишних вещей, который при первой итерации разработки не нужны.

Kopa

mOleg писал(а):

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

Минимальное ядро - это ещё не всё:) А как будет заполнен остальной слой
необходимый для создания ПО?
Есть, например, ОС kolibri разрабатывающаяся на минимально возможном
языке программирования Asm. но до окончательного дизайна ещё не известно
сколько необходимо времени:)

P.S. Кросс системы использовать можно? Или обязательно ядро системы
должно размещаться в ресурсах, например МК-контроллера и содержать
весь потенциально необходимый функционал автономно, включая и ASМ
и оптимизатор и библиотеки ( которых может и не быть на Форте)

idem

mOleg писал(а):

и нужно по сути даже не саму форт-систему иметь,
а набор слов, которые нужно реализовать
и их стековые соглашения
и порядок их написания.

Полагаю, что здесь можно начать с использования «железного» стека(какой есть в х86 процессорах). В синтаксисе интеловского всем понятного ассемблера – это PUSH/POP. Для Форт-транслятора получается что-то типа

Код:

:СЛОВО ( -- ) 0E / PUSH CS и т.д.

chess писал(а):

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

Не знаю, много ли тут вариантов.

chess

idem писал(а):

Не знаю, много ли тут вариантов.

Перечислю лишь мне знакомые:
1. Обычный массив с указателем. Логика движения указателя удаляющая - (n1 n2 --> n3 - результат операции)
2. Обычный массив с указателем. Логика движения указателя накапливающая - (n1 n2 --> n1 n2 n3) с периодической очисткой стека программистом.
3. Закольцованный массив с указателем. Логика движения указателя накапливающая - (n1 n2 --> n1 n2 n3)
4. Двойной массив с двумя указателями(первый массив для входных параметров, второй для выходных), с перебросом указателей с одного массива на другой.

пс. Логика управления указателем может меняться как программистом так и автоматически.
Для различных архитектур можно выбрать наиболее эффективную или сразу несколько с возможностью переключения.

минимальный форт-транслятор

Кто сейчас на конференции