Board.KolibriOS.org

Теперь пакет синтаксической подсветки опубликован в репозитории HippoEDIT среди остальных синтаксических схем(название Oberon-07) https://hippoedit.com/syntax_files.php?lang=ru
Кроме этого, синтаксические схемы размещены на GitHub https://github.com/hippoedit/syntax/tre ... /Oberon-07
Также существует тема на форуме HippoEDIT https://forum.hippoedit.com/syntax-files/oberon-07

Спасибо разработчикам HippoEDIT за помощь в допиливании синтаксической схемы — с такими людьми приятно иметь дело!
Алсо, теперь у меня есть Free Full License https://hippoedit.com/free_licensed_copy.php?lang=ru

Хорошо.

Заранее напишу список синтаксических изменений в новом компиляторе, влияющих на подсветку:

- Удалены предопределенные индентификаторы LONGREAL, LONG, SHORT. Встроенную процедуру COPY я всё же сохранил.
- Добавлен идентификатор BYTE.
- В вещественных константах допускается только символ "E", но не "D": 3.14E0.
- Удален системный флаг для записей [union]. Я не нашел ему применения и не использовал в своих программах. Может быть, это могло быть полезным при использовании библиотек, написанных на C, но так и не пригодилось. А вот [noalign] безусловно нужен, и этот флаг сохранен.
- Добавлен системный флаг для процедур [kosapi]. Действие то же, что и у флага [winapi] - stdcall с необязательным сохранением результата.

Тем временем, компилятор уже портирован в KolibriOS. Осталось только полностью портировать библиотеки и сделать генерацию obj-библиотек. По Windows сделано уже всё.
По кодогенерации есть еще небольшие недоработки.

Портировал FB2 Reader на новый компилятор. Размер сжатого бинарника остался таким же (+- несколько десятков байт). Но вот производительность не улучшилась... Вероятно, скорость работы упирается в системные вызовы и рантайм, который пока не оптимизирован (почти полностью написан на Обероне, машинных вставок мало).

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

Довольно много еще можно сделать для улучшения кодогенерации, но я это пока отложу - надо добавить второй таргет, тогда лучше будет видно, как усовершенствовать промежуточный код. Да и x86 мне порядком надоел. Сделаю перерыв, а потом начну делать другой таргет.

Провел сравнение с Black Box, тесты те же. Этот компилятор неоптимизирующий, но производит довольно хороший код (для неоптимизируещего), реализует язык Component Pascal. Впрочем, он только называется "pascal", а фактически это улучшеный Oberon-2, поэтому все тестовые программы подверглись лишь небольшой модификации. Здесь, конечно, результат не в мою пользу, но Black Box выигрывает не так уж много -- в 1.2 - 1.5 раза:

bubble 0.81
bubbleOA 0.69
fib 0.85 (0.94 если не использовать возврат из середины процедуры)
queens 0.68
blur 0.79

Видно, что скорость выполнения программ составляет примерно 70-80% от скорости Black Box.

Перенес на новый компилятор все "большие" программы.

Editor: размер уменьшился с 114 кб до 103 кб. О скорости ничего определенного сказать нельзя -- он и раньше работал удовлетворительно даже на старом P4 Celeron 2004 года выпуска.

FB2 Reader: загрузка процессора при быстром пролистывании уменьшилась примерно на 15%, остальное съедает рантайм, системные функции и операция копирования больших объемов данных при очистке графического буфера, которая не подлежит оптимизации. Открытие файла даже вроде немного замедлилось -- рантайм надо оптимизировать. В остальном -- ничего не изменилось.

TLS: вот здесь преимущество нового компилятора хорошо заметно -- скорость приема данных (AES-128) увеличилась в 2.2 раза.

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

Компилятор пока с закрытым кодом: надо чистить и добавлять второй таргет, чтобы всё встало на свои места.
Библиотеки старые, адаптированные для нового компилятора.
Такой вот пока, как тут один выражался, "полуфабрикат".

Поздравляю с релизом

Возможно это было
Попутно встретился проект оберона в нативный код x86 (пост от comdiv)
на данной страничке oberon foruma

P.S. А здесь на форуме Оберона
кто то хотел транслировать Оберон в Forth VM, но тему закрыл как не перспективную
А у меня остались некоторые наработки по трансляции С -> Forth на базе кода LCC компилятора и некоторого бэк-энда к нему. (отталкивался от проекта C2Forth у MPE LTD)

Leency wrote:Поздравляю с релизом

Спасибо.

Kopa wrote:Возможно это было
Попутно встретился проект оберона в нативный код x86 (пост от comdiv)
на данной страничке oberon foruma

P.S. А здесь на форуме Оберона
кто то хотел транслировать Оберон в Forth VM, но тему закрыл как не перспективную
А у меня остались некоторые наработки по трансляции С -> Forth на базе кода LCC компилятора и некоторого бэк-энда к нему. (отталкивался от проекта C2Forth у MPE LTD)

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

akron1 wrote:Оберон и Форт в чём-то похожи. Оба представляют больше академический интерес, чем практический.

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

P.S. По вопросу реализации "Паскаль" вариантов языка был такой проект D2Lang от 2004года
Авторские исходники в этой теме он сохранил

Это здорово, что проект развивается.

akron1 wrote:Здесь, конечно, результат не в мою пользу, но Black Box выигрывает не так уж много -- в 1.2 - 1.5 раза:

Ну, значит, есть куда стремиться

akron1 wrote:Снова возникла проблема с антивирусами.

На VirusTotal тоже некоторые(нонеймы) ругаются https://www.virustotal.com/#/file/abe6c ... /detection

Делаю промежуточное обновление.

Что нового:
- Ложная реакция антивирусов значительно уменьшена, хотя и сохраняется, особенно для графических приложений (для консольных меньше). Исполняемый файл компилятора проходит тест на VirusTotal с результатом 0/67 (было 18/67). Для этого понадобилось сделать отдельную секцию .bss, вместо расширяемой секции .data и нормальную секцию импорта, вместо LoadLibrary/GetProcAdr.

- Немного улучшена кодогенерация.

- Множество внутренних изменений, исправление ошибок.

- Добавлен специальный синтаксис для импорта функций из динамических библиотек.

Spoiler:

Импортированные процедуры

Синтаксис импорта:

PROCEDURE [callconv, "library", "function"] proc_name (FormalParam): Type;

- callconv -- соглашение вызова (stdcall, cdecl, winapi, kosapi)
- "library" -- имя файла динамической библиотеки
- "function" -- имя импортируемой процедуры

например:

PROCEDURE [winapi, "kernel32.dll", "ExitProcess"] exit (code: INTEGER);

PROCEDURE [stdcall, "Console.obj", "con_exit"] exit (bCloseWindow: BOOLEAN);

Объявления импортированных процедур должны располагаться в глобальной
области видимости модуля после объявления переменных, вместе с объявлением
"обычных" процедур, от которых импортированные отличаются только отсутствием
тела процедуры. В остальном, к таким процедурам применимы те же правила:
их можно вызвать, присвоить процедурной переменной или получить адрес.

Так как импортированная процедура всегда имеет явное указание соглашения
вызова, то совместимый процедурный тип тоже должен быть объявлен с указанием
соглашения вызова:

VAR
ExitProcess: PROCEDURE [winapi] (code: INTEGER);
con_exit: PROCEDURE [stdcall] (bCloseWindow: BOOLEAN);

В KolibriOS импортировать процедуры можно только из библиотек, размещенных
в /rd/1/lib. Импортировать и вызывать функции инициализации библиотек
(lib_init, START) при этом не нужно.

Это несколько увеличивает размер исполняемых файлов KolibriOS: размер "пустой" программы 7.5 кб (сжатый 3.0 кб).
"Пустая" программа включает в себя RTL, обертки для большинства видов системных вызовов, код для импорта из obj-библиотек, субаллокатор (несовершенный, но лучше, чем никакой). Всё это нужно для любой сколько-нибудь серьезной программы и этот код уже заранее встраивается в исполняемый файл. Для "больших" программ, это наоборот, может несколько уменьшить размер, т.к. таблица импорта + процедуры обработки этой таблицы занимают меньше места, чем вызовы GetProcAdr.

Остается улучшить библиотеки, рантайм и сделать нормальную обработку ошибок компиляции.

Поздравляю с релизом!

UPD
У меня не захотел компилится пример.
Также возможно ли сделать компиляцию исходника по энтеру в файловом менеджере?

Leency,

1) Там есть зависимость от регистра: если написано "MODULE Dialogs", то имя файла должно быть Dialogs.ob07 и при запуске из командной строки тоже ".../Dialogs.ob07 kos" (а не dialogs.ob07). Возможно, это следует пофиксить.

2) Компилировать прямо из файлового менеджера в общем случае неправильно: не имеет смысла компилировать произвольный модуль - только главный, кроме того, есть еще параметры компилятора (kos, obj, ...), которые нельзя указать из ФМ. Файлы исходных кодов обычно открываются с помощью текстового редактора (можно сделать ассоциацию файлов ".ob07" с TinyPad).
Но в принципе, работу с компилятором можно сделать более удобной. Возможно, я сделаю графический интерфейс при запуске компилятора без параметров (как FASM) с выбором файла в диалоговом окне, указанием прочих параметров и выводом туда же информации о ходе компиляции вместо консоли. А также, можно сделать, чтобы FASM запускался автоматически при завершении трансляции.

akron1 wrote:не имеет смысла компилировать произвольный модуль - только главный, кроме того, есть еще параметры компилятора

Может имеет смысл сделать файл-проект? В нём указать и главный модуль (и зависимости до кучи), и параметры. Тогда можно вызывать компилятор из файлового менеджера, указывая в качестве параметра только файл проекта.

UI для компиляции звучит заманчиво.
Спасибо за объяснение, я попробую с верным регистром.

Еще небольшое обновление:

- Сделан автозапуск FASM (путь указывается в Compiler.ini).
- В параметрах требуется указывать имя результирующего файла.
- Регистр в имени файла главного модуля больше не имеет значения.
- "Строки" можно заключать также в одиночные кавычки: 'строка'.

Репозиторий на гитхабе: https://github.com/AntKrotov/oberon-07-compiler
ссылка для скачивания архива: https://github.com/AntKrotov/oberon-07- ... master.zip

Хотелось бы кроссплатформенных примеров и возможность получать на выходе простой объектник MS COFF.