Оберон-клуб «ВЄДАsoft»

Уважаемый Артур!

Мне очень знакомы поиски "своей" реализации Оберон-транслятора. Долго облизывался на XDS, отложил по причине закрытости и неисправленных ошибок. POW! отмёл за явной заброшенностью. BlackBox очень понравился, но даёт весьма рыхлый машинный код, а также нету поддержки 64 бит. OPCL я ковырял долго, но смущает отсутствие биндингов к WinAPI, полу-ручная линковка .exe и, опять же, нет поддержки 64 бит. GPCP не умеет генерить нативный машкод и тоже весьма позаброшен. voc только для Linux'а (хотя автор обещает версию для Windows, но у него нет серьёзной мотивации, т.к. он сам не пользуется Windows). OO2C тоже заброшен, сложен, внутренне отличается от классики (ETH Oberon), и тоже версия для Windows создаётся какими-то магическими пассами. А хочется "из коробки"...

Оценив свои скромные силы, стало ясно, что хороший компилятор мы не потянем. Компилятор BlackBox написан очень серьёзной командой профессионалов, но и у него свои недостатки, которые не представляется возможным исправить так уж легко (неэффективность машкода, отсутствие поддержки команд > i486, отсутствие поддержки 64 бит).

Поэтому мы (команда XDev), исходя из своих требований, стали ваять собственную реализацию, но облегчили себе жизнь тем, что воспользовались готовым транслятором Ofront (Оберон-2 в Си) Йозефа Темпла. А именно версией, которая работает как подсистема BlackBox. Проект XDev умеет собирать код для различных платформ и процессоров, даёт промышленное качество кода (за счёт использования мощного оптимизирующего компилятора MinGW (GCC)) и имеет поддержку 64 бит. Также проект открытый, может, не очень активно, но развивается. Но нужно больше библиотек. Правда, скорее всего, соберутся библиотеки от voc, но они же Linux-ориентированные. Что-то я сам портирую, кое-что и не доделано. Мало документации. Так что проект, скорее, даже just-for-fun, чем на публику. Но он есть, пользуйтесь, пожалуйста, если интересно.

Частью проекта XDev выступает модифицированный нами транслятор OfrontPlus. (общие улучшения, а также добавлены некоторые фичи из Компонентного Паскаля). И вообще, если есть дельные предложения, давайте их реализуем, отчего же нет.

Ещё достоинства Ofront (и XDev): 1) есть живая поддержка — люди, разбирающиеся во внутреннем устройстве Ofront (Йозеф Темпл, Норайр Чилингарян, Олег Комлев, я); 2) наличие двух живых форков — OfrontPlus и voc; 3) наличие на базе Ofront транслятора Компонентного Паскаля; 4) возможность использовать разные компиляторы Си; 5) у меня есть версия транслятора Ofront для командной строки Windows, правда, она отстаёт от OfrontPlus. 6) Си-код, продуцированный Ofront'ом, выглядит чище, чем у OO2C.

Так что советую подумать ещё. Разработка своего компилятора во много раз сложнее, чем исправление найденной Вами в OO2C ошибки. А есть ли там ещё подобные ошибки — покажет только опыт использования.

Я тоже начал с XDS. Добротный компилятор. Но он не запускается на всех компьютерах, где он мне нужен, да и вообще это закрытый и поэтому мёртвый проект. Ещё я опробовал VOC, OO2C и BlackBox, посмотрел ActiveOberon, оригинальные проекты Oberon ETH (V5 и т. д.). Суть в том, что «нормального» компилятора Оберона (уровня и типа FreePascal или GCC) нет.

Единственное, чем могу порадовать - я разобрался, как запускать OO2C из-под Виндоуса и практически сделал версию, которая работает «из коробки». В пакете идёт урезанный MinGW с GCC (они нужны для компиляции) и однооконный редактор кода типа TurboPascal, который я написал (работает через Allegro 4, но я его перевёл и на SDL2). Прямо в редакторе можно компилировать и запускать программу. Для этого написаны небольшие внешние модули (для Виндоуса - на WinAPI, а для Линукса - на popen), с помощью которых редактор превращается в эмулятор терминала. Есть подсветка синтаксиса, выделение и копирование текста (см. снимок экрана ниже).
Но опять же, в OO2C есть дурацкий глюк, а компилятор действительно запутанный. Я этот глюк изложил в одной из веток на другом форуме по Оберону, было бы хорошо попробовать его починить, но я как-то завяз в этом коде, когда стал разбираться. Можно было бы даже перенести обсуждение этой ошибки на этот форум.

Я посмотрю XDev повнимательнее.
А вообще, смысл разработки своего компилятора состоит ещё и в том, что после такой работы в голове будет база для глубокого понимания кода других компиляторов. Можно будет со знанием дела устранять неисправности в них и участвовать в разработке.

Насчёт Блэкбокса:
Зачем нужна поддержка инструкций сверх набора 486? Только из соображений эффективности или есть ещё какие-то другие причины? И в целом, насколько неэффективный код выдаёт Блэкбокс? Например, при присвоении x := y + 1; происходит ли прибавление единицы прямо в регистр, в который загружена переменная y, или перед этим сама эта единица помещается в регистр?

Увы, но это так. Пожалуй, самое близкое, что есть, это трансляторы Оберона в Си (Ofront, OO2C) с последующей компиляцией с помощью того же GCC. voc следует этим же путём, просто "прячет" сишный компилятор с его ключиками в свою обёртку.

Это весьма интересно, Артур. Есть ли у проекта репозиторий или хотя бы страничка, где это всё добро можно скачать?

Я приблизительно так же разобрался с Ofront, дооснастил нужными мне фичами. Научился собирать версию для командной строки Windows (без CygWin), но сам её практически не использую. Использую версию, которая работает поверх BlackBox.

Если это интересно, могу поделиться результатами.

Мне кажется, перенос обсуждения этого глюка на наш форум ничего не даст. Ошибка, видимо, такого рода, что справиться с ней не хватит квалификации/мотивации у большинства оберонщиков. Я сам жду исправления подобного рода ошибки в GPCP и sdcc. И если с последним ещё куда ни шло, — команда активна, разработка идёт, делаются ночные сборки, — то с GPCP всё обстоит не так радужно. Боюсь, и в потрохах оптимизатора OO2C разберётся максимум автор и ещё 2-3 человека, которых ещё поди найди. Со своей стороны обещаю попробовать связаться со Стюартом Гринхиллом (разработчиком утилиты H2O) и рассказать ему об этой ошибке. Но насколько получится привлечь его к исправлению — трудно сказать.

Это по смыслу тот же voc, но работающий в Windows поверх BlackBox. Я адаптировал для него биндинги к WinApi, SDL, SDL 2. В поставке есть несколько библиотек и примеры. Но я не делаю упор на отладчики или что-либо подобное.

Безусловно.

1. Поддержка имеющегося набора инструкций нужна для разработки критичных к быстродействию программ, ну и чтобы идти в ногу со временем. И, разумеется, она нужна опционально.

2. Насколько неэффективный код выдаёт Блэкбокс? Не знаю. Но предполагаю, что до многих оптимизаций, реализованных в Delphi, Free Pascal и GCC (да даже в XDS) он очень серьёзно не дотягивает.

3. Насчёт "x := y + 1" — думаю, тут всё нормально. Преобразовать увеличение на единицу в инкремент одной машинной операцией легко. Я имел в виду более сложные оптимизации: свёртка констант, раскрытие циклов, размещение переменных в регистрах и т.п.

Компилятора или среды разработки?
Если компилятора - то вот пишут, исправляют, доделывают каждый почти день https://trac.inf.ethz.ch/trac/lecturers/a2/browser
Если среды, то не сложно сделать, на любом диалекте Оберона. Я пока притормозил разработку, хотя там и осталось чуть-чуть, надо не зацикливаться, а то накручу хреновен сам потом не разгребу...

К стати, все оберон диалекты делятся на два потока(или ветки), одни создают AST дерево и работают потом с ним. Удобно для компиляции на лету, переноса на платформы и виртуальные машины. И кодогенерация интегрированная в парсер.
Уж поверьте, я столько компиляторов оберона-паскаля на своём веку переписал, что по моему знаю все их тонкости и фишки...
Так что дерзайте и пишите... Самое сложное реализовать функцию Expression - так сказать ядро компилятора, всё остальное - это добавление синтаксических конструкций и в принципе на генерацию кода мало влияет...

А я вот не хочу писать ни компилятор, ни среду. Хочу готовое, мультитаргетное, с высококачественной кодогенерацией, с плюшками и богатым набором библиотек. И чтобы было живее всех живых, и можно было просто пописывать issues. Но увы.

A2 для моих задач не подходит по многим причинам: сложности сборки .exe для Windows, отсутствие биндингов к WinApi, мало таргетов, сомнительные расширения в диалекте AO (я предпочитаю O2/КП).

Я тоже не хочу... Но кому то надо приготовить.
Вот постепенно и ковыряюсь в WinApi и т.д.
Тем более получаешь более полную картину возможностей языка.

Помнишь ошибку выдавал OP2 при компилировании ББ-шного WinApi, так вот дело всё в стеке и переполнении...
И ничего не поделаешь пока не перепишешь работу с импортом DLL... Ну и мелочи разные...

Но... WinAos и AO дают готовые наработки, рабочие и проверенные уже на операционной системе...
Как пример Zip библиотеки ну как не крути не работают в ББ... Либо работают не правильно, и не знаешь
где подвох будет...

Так фиксить надо. И тоже кому-то Или портировать из того же A2.

Конечно надо, вот я профиксил проблему Оберон ОС - черный экран при загрузке, выложил пример здесь.
Думаешь кому то интересно было? Никому... Ну, значит моё будет работать на железе любом, остальные пусть ищут
И это не из-за вредности, а из-за того, что я пишу и изучаю код для самообразования, понимания, обучения...
Как только я понял и разобрался - охота пропадает... Потом конечно заново вдохновение приходит, но кричать уже не хочется...

Серж, а ты с этой проблемой сам столкнулся или просто где-то о ней прочитал?
Потому как, вероятно, ты имеешь в виду библиотеку Zlib. Её код Владимир Сидоров портировал с ETH Oberon/AOS и, насколько я знаю, довёл до ума. Пару багов конечно выловил, о них было написано на форуме. Но эти же баги были и в AOS-версии. Сейчас всё работает.

Может быть, но я пробывал на PNG картинках... Блин, в АОS работает как часы, там в принципе всё на этом и построено, а в ББ как то криво работало и не все форматы, может я просто не разбирался и не вникал... Но.. Если в одном диалекте работает без проволочек, а в другом немножко косячит я естественно выбираю первый вариант (на всякий пожарный).
Далее.. AOS - это всё таки операционная система, да сборщик мусора (как и все которые я видел, исключение составляет О7 от ExaProg) там не айс, но НАКОНЕЦ-ТО в АОS-е занялись этой проблемой, я что бы не выделываться использовал возможности ОС для выделения - освобождения памяти, поэтому в редакторе память выделяется-удаляется динамически. Как пример если я выделю и скопирую текст, а потом сотню раз его удалю-вставлю в поле вывода у меня не откушается 100Мб и более .
Ну вообщем иду по пути Николая Вальдемаровича - пишу что бы узнать, попробовать, отдать народу на изучение...
Так что если кому что не ясно в ЛЮБОЙ реализации Оберона, задавайте вопросы, всегда буду рад помочь и подсказать...

Самый красивый к стати Амига Оберон, по написанию кода

ЗЫ...
ZLib работал ещё до AOS-а, в Oberon0 от ETH, оно там в память модули грузило изначально (вернее после ARC формата)...
Я даже смотрелку образов FDD делал, типа WinImage только для N2K файловой системы... Это Виртовская фс, она там до сих пор встроена
И более того, ОСЬ построена (ядро) так здорово, что в принципе прикручиваются любые файловые системы, то, что в линуксах делалось 15 лет... Да и в виндах то же...
В смысле не только файлоые системы, но и драйвера и тд. и тп.

FoxCompiler полностью переписан в этом же принципе, фронт-энд отделён от бэк-энда, крути любые компиляторы для и на любых платформах. Рантайм конечно же тяжеловат, но!!! кто сейчас на память то оглядывается?