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

Твердыня модульных языков
Текущее время: 28 мар 2024, 15:01

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 11 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 18 дек 2012, 23:07 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Про Ofront — продолжение разговора с Ильёй Ермаковым в привате.

Илья Ермаков писал(а):
Добрый день, Олег!
Здравствуйте, Илья Евгеньевич.
Илья Ермаков писал(а):
Любопытно про Оминк... Непонятно только, когда выложат.

Да сам жду не дождусь. :) Но может и не выложат никогда, не хотят порочить своё имя сырым продуктом, видимо. У них мало интереса делать что-то серьёзное безплатно. У меня больше надежды на профессора K John Gough с его GPCP for LLVM.
Илья Ермаков писал(а):
А как вообще Офронт, насколько применимая и не-сырая вещь?

Офронт по моим субъективным ощущениям очень продуман и вылизан, Йозеф Темпл реализовал его в духе Оберонов — чрезвычайно гибким в настройках и широко функциональным. Если с ooc надо шаманить с бубном, чего не выдержали мои нервы, то вся установка Ofront'а сводится к распаковке архива. В целом, получился стабильный продукт, но с некотрыми "но.".

Во-первых, это Оберон-2. Т.е. юникодовые строки в чистом виде не присутствуют. Но работать с ними можно, объявив в файле настроек строковый тип как двухбайтовый (при этом теряя возможность работы с однобайтовыми строками). Можно иметь 32-битный INTEGER и 64-битный LONGINT, это всё настраивается.

Изначально, как я понимаю, Ofront разрабатывался для портирования системы ETH Oberon на новые архитектуры через Си. Из-за чего он весьма завязан на библиотеке libOberonV4.so, реализующей Оберон-рантайм и различные библиотечные модули в стиле ETH Oberon. Насколько хорошо это получилось — смотрите эту ссылку:
Цитата:
Oberon System V4 (Kepler version, Linz, Austria) translated by Ofront and running on tablet PC Nokia N810 — http://norayr.arnet.am/weblog/?p=668

Благодаря кастомизабельности Офронта его можно отучить и от ядра, и от Оберон-рантаймов, и работать в весьма минималистичном стиле через libc или ещё как-то иначе.

Ofront есть в виде подсистемы BlackBox и для командной строки Linux, но целевая платформа для разработанного приложения — по задумке Linux, с подключением к целевому приложению библиотеки libOberonV4.so, так что платформа Win32 остаётся неподдержанной (что не мешает всё-таки разрабатывать для неё на Офронте без libOberonV4.so). Можно ли поддержать Windows? Несомненно да. Просто Темплу это не было нужно, как и собирать консольную версию Офронта для Windows.

Илья Ермаков писал(а):
У них есть метаинформация во время выполнения? Т.е. могу ли я реализовать дин. модульность, например? По типу Борланд BPL - когда несколько модулей собираются в DLL, имеющую предопределённые специальные точки входа (типа ДатьСписокМодулей(), ДатьСекциюКодаМодуляХ(), ДатьСекциюДанныхМодуляХ()).

Метаинформация во время исполнения есть, даже регистрация процедур без параметров как команд (средствами ядра). Динамическая модульность тоже есть. Сборка мусора, само собой, есть.
Цитата:
The following list and the subsequent explanations give an overview of the most important highlights of Ofront.

• full Oberon-2 language support
• extensible module interfaces
• fast translation
• parameterization for arbitrary C compilers, ANSI and K&R
• highly compact and efficient run-time system
• automatic precise garbage collection
• advanced heap management (growth on demand, finalization)
• commands and modules preserved
• dynamic loading of modules or subsystems
• interfacing with C or other foreign languages
• clean and human-readable C code, no warnings
• information hiding preserved in the generated header files
• multiple libraries available
• command-line version and integrated development environment

Для серьёзной работы с Офронтом не помешает хорошее знание языка Си. Чего по моему мнению больше всего не хватает Офронту — творческого подхода к нему со стороны коммьюнити. Тем более, Темпл отпустил его в широкое плавание, чего нельзя сказать, например, про XDS-C.

В принципе, читайте вот эту доку, вопросы отпадут:

https://github.com/Oleg-N-Cher/BB-XDev/ ... ntUser.doc


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 19 дек 2012, 15:11 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Илья Ермаков писал(а):
Спасибо за ответ, Олег, интересно.
Я пропустил когда-то Офронт мимо ушей и до этой переписки считал, что речь об OOC :)

Буду смотреть, у меня есть в задумках на следующий год вывод КП на многоплатформенность через С. Хочется кросс-разработки: отладил серверное приложение в ББ, потом собрал под нужную платформу и залил на сервак :)

Олег, а Вы не залезали внутрь офронта?
Какой компилятор там использован? Насколько "вменяемый" там уровень синтаксического дерева, интересно...
Доброго времени суток, Илья.

КП через Си — прекрасная идея, и мне тоже очень хочется пожать плоды кроссплатформенности, работая на любимом КП. И здесь, видимо, наиболее разумны 3 направления: компилятор КП с бэк-эндом в GCC, в LLVM и, наконец, в Си. Притом для последнего варианта я хотел бы видеть в этой роли именно доработанный Ofront.

Многим людям (особенно заочно) не нравится сама идея трансляции в Си. Менее знакомые с Оберонами спрашивают — почему бы не писать прямо на Си. Но мой опыт показывает, что в связке можно добиться максимальной пользы и от уровня Си, и от уровня Оберона. Она открывает перед Оберонами возможности, которых им сильно не хватает. Например, разрабатывать на Оберонах для микроконтроллеров можно, но только для ARM. Ofront же делает доступной такую разработку практически для любых контроллеров любой архитектуры и разрядности. Так что у связки Оберон-в-Си есть свои преимущества.
Илья Ермаков писал(а):
Олег, а Вы не залезали внутрь офронта?
Какой компилятор там использован? Насколько "вменяемый" там уровень синтаксического дерева, интересно...
Илья, Вы мне не поверите, но базой для компиляторов BlackBox, Ofront и даже OPCL (ETH Oberon) является один и тот же компилятор OP2 (Oberon Portable), описанный в этом документе:

https://github.com/Oleg-N-Cher/OPCL/blob/master/Docu/OP2.Paper.pdf

OP2 не использует COCO/R — там, как говорится, вручную закодировано. Но добрая часть кода этих трёх компиляторов сильно похожа, сам сравнивал.

GPCP — тоже интересная база для наращивания путём добавления новых бэк-эндов — разработан с помощью COCO/R.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 20 дек 2012, 08:57 
Не в сети
Администратор

Сообщения: 10
OP2 - это хорошо...
Конечно, я в курсе, что это за штука.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 21 дек 2012, 21:34 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
О, вижу по Вашим настроениям, что Вы не прочь приложить руку к доработке Ofront'а до транслятора с языка Компонентный Паскаль. :) Держите, пожалуйста, в курсе насчёт шагов в этом направлении. Вывод КП на многоплатформенность меня очень интересует. Даже согласен поучаствовать, может быть и не как программист, но косвенно; в этом польза тоже есть. Я общался на эту тему с некоторыми людьми, и что они мне ответили — можно прочесть в теме Компонентный Паскаль и LLVM.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 22 дек 2012, 17:41 
Не в сети
Администратор

Сообщения: 10
Не прочь-то не прочь, но пока сил нет на это. Но более краткого пути к многоплатформенности и даже узко говоря 64-битам сейчас я не вижу.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 22 дек 2012, 17:48 
Не в сети
Администратор

Сообщения: 10
Моё мнение по этому вопросу:

Конечно, идейно "чище" делать без промежуточного Си.
Тут вопрос в том, кто воспринимает компиляторную тему как самоценную, а кто нет.

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

А в плане "навёрнутости" коды многих процессоров гораздо "загаженнее", чем Си. А пром. коды таких машин, как LLVM, ещё и гораздо больше подвержены риску изменений со стороны их разработчиков, чем уже теперь ставший стадартом ЯП.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 22 дек 2012, 21:31 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Я согласен про краткий путь через Си. Но и сейчас он только для Оберона-2, а для КП ещё предстоит.

Понятно субъективное ощущение наличия риска полагаться на не свой проект, который развивается в русле производитей/исследователей, и нет рычагов чтобы повлиять на этот процесс (И почему данный факт не смущает многих почитателей .NET'а? Верят в непогрешимость Самого Компактнософтого Непотопляемого Брата?) Я всё же полагаю, что базовая совместимость в LLVM с единожды зафиксированным SSA intermediate language будет соблюдена, а функциональность может быть наращена поверх без потери совместимости с этим стандартом. Целесообразность такой совместимости проистекает из уже неплохого багажа готовых проектов, базирующихся на LLVM (хотя бы тот же clang), перестройка которых на существенно отличающееся внутреннее представление может быть весьма болезненной.

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

Почему я считаю LLVM явлением существенно более прогрессивным, чем .NET/JVM. Как видим, ситуация у GCC с фиксацией внутреннего промежуточного представления обстоит сейчас даже несколько хуже, чем у LLVM — их решение уже распалось на 3 ветви, поэтому путь LLVM предпочтительнее GCC, хоть и LLVM может в итоге распухнуть тоже. Но создание нового не только фронтэнда (новый ЯП), но и бэкэнда (новый процессор или виртуальная архитектура) для LLVM — вполне посильная задача даже для энтузиаста. И не придётся делать мощный линкер (в составе LLVM они уже есть). И оптимизацию уже сделать гораздо проще. Как подтверждение привожу форумную ветку разработчика LLVM-бэкэнда для восьмибитного процессора Z80. Наглухо запаянные .NET и JVM здесь лузеры, ибо абсолютно не приспособлены для такого расширения дополнительными оптимизаторами, навешиваемыми поверх как плагины, а также бэк-эндами.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 23 дек 2012, 16:24 
Не в сети
Администратор

Сообщения: 10
В общем, в сравнении C и LLVM ещё нужно думать - что лучше :)


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 08 апр 2014, 16:07 
Не в сети

Сообщения: 22
Олег Чередниченко писал(а):
Я согласен про краткий путь через Си. Но и сейчас он только для Оберона-2, а для КП ещё предстоит.

А Вы не рассматривали обратную задачу: КП и/или Активный Оберон в качестве бэк-энда?


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Ofront (Oberon-2 to C Translator)
СообщениеДобавлено: 08 апр 2014, 17:12 
Не в сети

Сообщения: 22
Допустим, разрабатывается портабельное ПО, которое мы хотим собрать под КП, XDS, Ofront-C (cc) и даже AOS.
Допустим, решены проблемы привязки к конкретной платформе (с помощью условной компиляции или переходной платформо-зависимой библиотеки, как хотите).

1. Будет ли переносим программный код, если он написан на Обероне-1 ?
Да

Допустим, мы разрабатываем ПО с широким применением ООП.

2. Будет ли переносим программный код, если он написан на Обероне-2 ?
Нет

Возникла работа с методами - и для КП уже нужно ABSTRACT или EXTENSIBLE, а для AO - OBJECT.

Поэтому представляется разумным иметь Oberon-2 front-end и множество back-end'ов, например, C, КП, AO.
Также, представляется, что back-end'ы проще в реализации, чем давать на вход КП


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 11 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club