Компилятор Oberon-07

High-level languages programming questions
  • Хорошо.

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

    - Удалены предопределенные индентификаторы 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" у меня раньше был выключен, то ли обновился... Ну и ладно, пока не важно.

    Компилятор пока с закрытым кодом: надо чистить и добавлять второй таргет, чтобы всё встало на свои места.
    Библиотеки старые, адаптированные для нового компилятора.
    Такой вот пока, как тут один выражался, "полуфабрикат".
    Attachments
    oberon-07.rar (162.43 KiB)
    Downloaded 511 times
  • Поздравляю с релизом :)
    Last edited by Leency on Wed May 23, 2018 2:37 pm, edited 1 time in total.
    Из хаоса в космос
  • Возможно это было :)
    Попутно встретился проект оберона в нативный код 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.

    Остается улучшить библиотеки, рантайм и сделать нормальную обработку ошибок компиляции.
    Attachments
    oberon0716.zip (267.28 KiB)
    Downloaded 355 times
  • Поздравляю с релизом!

    UPD
    У меня не захотел компилится пример.
    Также возможно ли сделать компиляцию исходника по энтеру в файловом менеджере?
    Attachments
    SCREEN_1.PNG
    SCREEN_1.PNG (62.37 KiB)
    Viewed 10246 times
    Из хаоса в космос
  • 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.
  • Who is online

    Users browsing this forum: No registered users and 2 guests