OberonCore

Видимо, пора уже создать такую тему. Итак, встречайте: Ofront+. Форк транслятора Йозефа Темпла Ofront на базе портабельного компилятора OP2 (ETH Oberon). Текущий статус проекта: стабильный, фичи допиливаются по мере необходимости. В планах есть много задумок: добавить, кроме Оберона и Оберона-2, ещё Компонентный Паскаль, Оберон-07 и экспериментальный диалект Оберон-3. Также я думал про совместимость с языковыми расширениями GPCP. Кое-что из задуманного уже реализовано. Если возьмёте транслятор в работу, будем активно развивать его вместе с вашими потребностями. Я на это очень надеюсь. Мне несколько обидно, что неразвивающийся Vishap/voc котируется по рейтингам выше, чем более прогрессивный и мощный Ofront+. Давайте менять эту ситуацию!

Отличия Ofront+ от Ofront/voc:

• Новый экспериментальный диалект Oberon-3 (на основе Oberon-07, Component Pascal и др.).

• Выводится имя модуля/позиция для любой ошибки времени выполнения, HALT и ASSERT.

• Системные типы: INT8, INT16, INT32, INT64, ADRINT.

• Можно выполнять арифметические операции над типом BYTE (Oberon-3 и Component Pascal).

• Неограниченная длина строковых литералов (в Ofront/voc макс. 255 символов).

• Поддержан SYSTEM.VAL(INTEGER, {80000000H..0FFFFFFFFH}) при описании констант 32-битного типа (иначе они считаются 64-битными).

• ASH and SYSTEM.LSH возвращают результат типа INTEGER для аргумента типа <= INTEGER и результат типа LONGINT для аргумента типа LONGINT. Это позволяет использовать сдвиги без оверхеда в виде сдвига 64-битного значения.

• Поддержан символ «_» в идентификаторах.

• Ofront+ для Windows работает под Windows 9x. Ofront+ для Linux поддерживает 32 и 64-битные системы.

• Поддержка исходников в кодировке UTF-8 (с или без BOM) с EOL как 0DX (система Oberon), 0AX (UNIX/Linux) и 0DX+0AX (Windows).

• «Правильный FOR» (концепция Олега Комлева), константные массивы, доступные в Oberon-3 (пока только в Ofront+ для BlackBox).

• BITS(), ORD(set), LEN(string$), str1 := str2$, IN-параметры процедур (Component Pascal).

• ORD(bool), ORD(set) поддерживается в Oberon-3.

• Системные флаги: VAR [nil], ARRAY/RECORD [untagged], POINTER [untagged] как в BlackBox.

• Расширенные возможности для описания привязок к чужеродным библиотекам, системный флаг [stdcall].

• В одном проекте можно использовать модули, написанные на языках Oberon, Oberon-2, Component Pascal и Oberon-3.

• Испытано с GCC/MinGW, Intel C++, SDCC и даже Borland Turbo C.

Я начал этот проект чтобы иметь настоящий инструмент, а не игрушку. И сейчас это довольно хороший способ получить решение для архитектур ARM/x64 на Обероне-2 или Компонентном Паскале, хотя и подмножестве. Меня Ofront+ уже более чем устраивает в том виде, в котором он есть, но также я оказываю поддержку своим пользователям при решении возникающих проблем. Так что буду рад сотрудничеству.

Ссылки:

• OfrontPlus@GitHub

• XDev (базируется на Ofront+)

• Видеопрезентация «Трансляция языков Оберон-семейства в Си. Проекты Ofront+ и CPfront» с Дня Оберона-2018

А CPFront вы не смотрели?

Смотрели. Об этом было в моём докладе на Дне Оберона-2018. Он не готов для 64 бит и ядра нет. Но конструктивно он близок к Ofront, так что я хочу их срастить по мере сил, со временем.

А описание Oberon-3 есть?

А что подразумевается под готовностью для 64 бит?

Конструктивно то понятно, это Ofront какой-то промежуточной версии переделанный под КП.

Да, как им пользоваться-то?

Готовится.

Как минимум, неиспользование везде, где можно, INTEGER в качестве адреса. А в идеале - наличие адресного системного типа. Да, те модули, которые являются CPfront'ом, можно переделать под 64 бита, но поскольку всё увязано на BlackBox, то кто будет переделывать фронт-энд? Потом нужно будет ввести несколько наборов символьных файлов для разных разрядностей. Не всё так тривиально, как Вы думаете, Борис.

Там есть QuickStart.txt и примеры программ со скриптами их для сборки. Если что-то конкретно непонятно, дайте знать)

Как скомпилировать хелловорд?
Он не находит символьных файлов, да их и нету. Как сделать, чтобы были?

Есть они. Цитирую QuickStart.txt:

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

Поиск по "*.sym" не дает результатов. Может они и есть, но где?

А-а, я понял отчего у Вас нет *.sym, Trurl! Раньше они присутствовали в репозитории, но потом Иван Денисов заметил, что нет смысла хранить там файлы, которые легко сгенерировать. Я подумал — что-то в этом есть. И убрал.

Просто запустите Lib/Bin/o2c для 32-битной системы и Lib/Bin/o2c64 для 64-битной.

Ура! Заработало! (^◔ᴥ◔^)

А я и не думаю, что всё тривиально.

Планируется ли добавить автоматическую сборку исполняемых файлов помимо генерации кода на C?

В Ofront+ добавлены арифметические операции DIV0 и REM0. Благодарю ComDiv'а за помощь.
Подробнее здесь: https://github.com/Oleg-N-Cher/OfrontPlus/issues/55

Я думал о чём-то подобном. Такая прослойка между транслятором Оберона и компилятором Си, которая будет переводить свои опции командной строки в gcc'шные. Серьёзно? Кому-то такое ещё надо? В voc проделана эта работа, и поэтому voc хорош? Не очень понятно, зачем изобретать свои опции и транслировать одни опции в другие. К тому же, это жёсткая завязка на определённый компилятор Си. Плюс понадобится привязка к структуре проекта, расположению библиотек и т.д. (что мне не нравится в voc).

Вопрос к пользователям Ofront+. Чего больше всего не хватает в трансляторе? На какое направление его развития нужно сделать упор в первую очередь?

Я уже много раз об этом говорил: хотелось бы готовые *.c для жму/пинусов вместо бинарей.
Не обязательно их ложить в репы, пусть транслируется автоматически и выкладываются куда-нибдь на фтп или в релизы на шитхабе (это наверняка делается как-нибдь автоматизировано) вместе со свежими бинарями.

Навёл порядок с шестнадцатеричными литералами в разных Оберон-диалектах.

• https://github.com/Oleg-N-Cher/OfrontPlus/issues/56

Ну хорошо. Мне это не упёрлось, но раз человек просит, почему бы нет.

Здесь кто-нибудь мог бы мне помочь с настройкой Travis CI или AppVeyor?

• https://habrahabr.ru/post/329264/

• http://reangdblog.blogspot.com/2015/09/appveyor-travis-ci-windows.html

Улучшена поддержка Oberon-07 (опция -7): добавлены встроенные функции FLOOR и FLT.

• https://github.com/Oleg-N-Cher/OfrontPlus/issues/57

Кто-нибудь использовал Ofront+ для компиляции в DLL?
Я линкую модкли в DLL (mingw-w64), в принципе работает, но почему-то
не запускается секция инициализации модулей.

А финализации модулей в Ofront+ нет?

Я использовал.

При загрузке DLL и не должно само инициализироваться. Механизма типа DllMain там не предусмотрено. Инициализацию делает вызов Module__init() через макрос __IMPORT(Module__init). Ключик -d при создании DLL юзаете?

Пока нет. Сделаем CLOSE как в КП.