OberonCore

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

Иван Андреевич, я не занимаюсь BlackBox1.8. Я занимаюсь МультиОбероном. Мультиоберон включает в себя 3 бэкенда: Omb нативный, Omf на базе OFront, Oml на базе LLVM. А еще рантаймы, загрузчики, средства разработки. Каждая новая версия включает в себя Omb, Omf, Oml. Это везде написано, а Вы как-то трактуете по своему. И когда мы обсуждали, я говорил об этом, что можно брать инфраструктуру МультиОберона для написания других бэкендов. И даже Вам конкретно предлагал выше по тексту. Так что, если хотите делать Omb64 и есть пассионарность, полный вперед. Я помогу.

А Вы и Антон мне предлагали какую-то конкурирующую разработку, мимо МультиОберона. Естественно, в ней я участвовать не буду.

Давайте не будем делать поспешных выводов про конкуренцию. Вижу, что есть недопонимание какое-то. Антон ведь вам чётко выше написал, что его символьная таблица может быть странслирована на вход мультиоберону в перспективе и наоборот. И вы тоже на встрече сказали, что какие-то хорошие наработки можете включить в МультиОберон. Считаю, что эти два проекта объединятся в лучшем виде. Но это потом, когда будет всё отлажено и согласовано. Нужно время. Я просто даже не могу нормально сесть и разобраться с вашими наработками пока.

Вот теперь правильные слова. Успехов!

Но пока Oml не быстрее Omb. А мне кажется, некоторые ожидают, что LLVM автоматически даст прирост производительности.

Оберон всегда тяготел к железу. Хочется сохранить эту приверженность традиции.

Благодарим первого крупного спонсора — компанию Mobatec! Сегодня они сделали первый благотворительный взнос 250 евро на развитие Гершеля.
https://mobatec.nl
Мобатек разрабатывают и продают программное обеспечение для моделирования производственных процессов и обучения персонала.

Опубликована длинная заметка с обоснованием проводимых изменений в части фронтенда
https://vk.com/@herschelcompiler-zachem ... i-simvolov

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

Продолжение истории вызывает интерес.

По состоянию на 10 сентября:

https://vk.com/herschelcompiler?w=wall-196590190_47
http://herschel.oberon.org/2020/09/09/post/
https://twitter.com/HerschelCP64

Не нашёл и в репозитории. Их можно хранить вместе с основным кодом.

Они в файле:
Hr/Rsrc/TesterPanel.odc

Думаю, что мы с Антоном как-нибудь запишем видео-встречу, как этим добром пользоваться. Там он создал некоторую инфраструктуру для тестирования, так что сразу и не "въедешь".

Как насчёт того, чтобы наоборот, делать тесты не завязанными на инфраструктуру? Чтобы их было проще задействовать вне зависимости от проекта?

Тесты находятся в документе Hr/Rsrc/TesterPanel, каждый тест - в отдельной складке, пронумерован и снабжен названием. Эталонные результаты следуют за текстом модуля.

+>Test99: Unresolved forward type references<+
->MODULE M;
...
END M.
+>Эталон<+
<-
+>Test97: String selectors<+

Часть тестов предназначена только для фазы анализа (фронт-энд), а другие - еще и для фазы синтеза (генерация кода) и фазы исполнения программы. Для каждой фазы - свой эталон.

PS
Тексты ББ мощны, красивы и лёгки;
им где найдешь ты подобных?

По состоянию на 16-е октября Антоном реализовано:

https://vk.com/herschelcompiler?w=wall-196590190_112

Путь к славе.

Может, и так ). Но напомню себе, что


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

И еще вопрос: есть ли где-то описание формата OCF? Понятно, что сам компилятор и загрузчик являются его исчерпывающими описаниями; но уж больно больно вникать в такие описания ).

Так в каталоге Dev/Spec!

Великолепно! Благодарю!

Из заметки:


Вирт пишет в книге «Построение компиляторов», что он не использует расширение типов потому, что это усложняет код, и в данном месте это не нужно. Т. е. чтобы не умничать. Но в Oberon-07 всё как-то проще сделано, без всяких intval'ов. Там есть поля с названиями вида «a», «r» и есть маленькая табличка, где написано, что что означает. Я делал также, лично у меня особых трудностей не возникло. Может быть, из-за других, менее значащих (и поэтому не столь сбивающих с толку) названий полей и типов.

Например, в ББ записи, которые обозначают типы, называются почему-то структурами. Хотя структурой можно назвать записевый тип, ну и, например, массив... ну и процедурный тип, допустим. А INTEGER, BOOLEAN и прочее? Зачем там слово «структура»? Оно действительно сбивает с толку. В Обероне-07 это называется просто Type. То есть есть Object (всё, что в компилируемой программе имеет имя: константа, переменная, (пред-)объявленный тип, процедура или модуль), а есть Type (не имеет имени, обозначает форму типа, включая и базовые типы, и записи, и массивы, и процедуры). А в генераторе есть ещё Item, который представляет собой вещь, которую компилятор «держит в руках» непосредственно в процессе компиляции тел процедур. То есть при объявлении переменных и т. п. у нас есть только Object'ы и Type'ы, они помещаются в так называемую таблицу символов. А при собственно компиляции, когда вот-вот придёт время уже выдавать действительный машинный код и в процессе такой выдачи, появляются Item'ы, ссылающиеся на эти Object'ы. Причём Object'ы и Type'ы — переменные динамические, а Item статические, т. к. имеют смысл только в пределах соответствующих запущенных в данный момент процедур компиляции.