DEmbro был в коме более месяца. Разработки не только не велись, но даже скомпилировать проект из транка было невозможно, т.к. makefile для сборки был в подвешенном состоянии. Вчера, наконец, я смог выделить время и реанимировал компиляцию в линуксе, а сейчас приступил к написанию универсальной сборки, чтобы и в posix-окружении, и в windows работало, причём без конфигурационных инструментов. Пришлось использовать небольшой хак. :)
У меня в голове есть несколько глобальных мыслей о DEmbro, и я решил их потихоньку оформлять в виде текстов в этом блоге. (Кстати, заметил, что то, что в моей голове выглядит мощно, в записанном виде получается чем-то незначительным или бредовым. Поэтому не претендую на то, что тут что-то умное.)
Мысли о «собери DEmbro сам»
Я понял, что не хочу иметь большую монолитную систему, какими обычно являются компиляторы/интерпретаторы. Хочу получить эдакий конструктор «собери DEmbro сам», с возможностью определять базовый набор команд в бинарнике, особенности DEmbro-машины и прочее. Польза от этого следующая:
- Лёгкость в совершении глобальных изменений.
- Возможность в случае возникновения специфической задачи быстро сделать специализированное под эту задачу ядро DEmbro
- (Следствие пункта 1.) Возможность тестирования и прикидок -- можно попробовать несколько решений и посмотреть какое из них ведёт себя лучше.
Приведу пример — RetroForth. Это талантливо написанная реализация одного из диалектов форта, но полностью лишённая гибкости. А именно: всё заточено под 16-битный асм, каждая следующая команда реализуется через предыдущие, в качестве шитого кода только машинный код. Нет возможности изменить что-то в ядре (форматы хранения словарных статьей, базовый набор команд, производимые оптимизации). И т.д.
Технически гибкость достигается, понятное дело, разделением кода на части, связи между которыми минимальны. И первый шаг к этому я уже сделал: команды дембро описываются в отдельных файлах со своим форматом, из которых собираются исходные коды. Как минимум я уже получил независимость реализации дембро-машины от команд, которые доступны в языке, и как следствие возможность лёгкого отключения групп команд (например, можно скомпилировать ядро без команд для работы с плавающей точкой). В идеале у меня есть идея записывать реализации этих команды не на паскале, а на каком-то совсем своём ограниченном промежуточном языке, который легко преобразовывать в конкретный (паскаль/си/etc), тогда можно бы было реализовать дембро-машину на разных языках программирования, что повысило бы переносимость.
Мысли о совместимости версий
Исходя из предыдущей идеи, у DEmbro не должно быть как таковой
линейки версий, а должно быть большое дерево разновидностей с кучей диалектов, не совместимых друг с другом. Тем не менее, некую основную ветвь я буду разрабатывать, под неё писать спецификацию.
Однако, я не хотел бы себя загонять в рамки бесконечной поддержки предыдущих версий. Т.е. если я захочу переназвать кучу команд, изменить тонкости их поведения и т.д., то я это и сделаю (и уже делал). Это, конечно же, приведёт к тому, что код, расчитанный на предыдущие версии дембро, в новых версиях не будет работать. Чтобы, однако, не терять старый код, будет возможность включать режим старых диалектов, как-то так:
include" units/dialects/dembro.0.23.de"
DIALECT DEMBRO0.23
// код, расчитанный под старую версию DEmbro
\DIALECT
// тут снова можем писать код для новой версии DEmbro
Технически это не должно быть чем-то сложным. Как минимум, уже сейчас есть механизм словарей, обеспечивающий лвиную долю функционала.
Возможно, даже, будет что-то типа такого :)
include" units/dialects/retroforth.de"
DIALECT RETROFORTH
...
\DIALECT
Читать дальше......
