OberonCore

Да, правда, подпорка на метаинформацию таки потребуется...

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

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

Да и front-end к gcc мало интересен, тем более, что и он есть.

Где?

Дался Вам этот gcc. Стандартные .o умеют создавать и другие. Тот же XDS. И не только он.
Договаривайте.

Не хотелось чтобы этим Ваше участие и ограничилось. Но это сугубо мое мнение. Решать всё равно придется Вам.

Безусловно, но посоветовать какие ещё шаги можно предпринять, вы же можете.

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

Модераторы тихо сползли под стол, за терминалами...

Мда, ну вы тут и разошлись, видно тема действительно актуальная.

Дабы повернуть дискуссию в конструктивное русло, сформулирую свое видение техзадания:

1.) целевая аудитория - непрофессиональные программисты; # сам такой
2.) область применения - компилятор общего применения; # мне нужен для написания небольших и средних приложений под распространенные оси
3.) целевые платформы - i386 и, возможно, ARM;
4.) целевые оси - WindowsNT и старше, возможно WinMobile, Linux, всякие UNIX-ы, возможно BeOS/Haiku;
5.) исходный язык - Oberon-2; # мне так хочется
6.) выход - объектный файл (coff и elf для начала) и символьный файл; # для большинства осей достаточно
7.) язык реализации - Oberon-2; # другие языки знаю плохо (я вообще не программист)
8.) статическое и динамическое связывание с библиотеками написанными на других языках; # куда сейчас без этого
9.) сборка мусора - возможность статического и динамического связывания;
10.) сложность употребления - невысокая; # небольшое к-во. настроек (см. пункт 1)
11.) оптимизация - простая и без особых настроек и тонкостей; (см. пункты 1 и 2)
12.) лицензия - какая-нибудь открытая; # GPL, MPL, BSD или еще что-нибудь в этом роде.


Варианты решения:

1.) написать с нуля
достоинства - можно сделать все как хочется
недостатки - большой объем работ, нужна команда опытных программистов
2.) написать FrontEnd к gcc
достоинства - не нужно писать BackEnd, большое количество целевых платформ
недостатки - программистов нужно меньше чем в пункте 1, но они тоже должны быть профессионалами, довольно высокая сложность употребления (gcc)
3.) написать BackEnd к oo2c
достоинства - не нужно писать FrontEnd
недостатки - довольно специфическая реализация Оберона, также нужны профессионалы
4.) использовать в качестве затравки POW!
достоинства - под винду он уже работает, генерит объектные файлы в coff, модульный, структура близка к компилятору OP2 на который есть внятная документация
недостатки - не совсем понятна ситуация с лицензией, я получил предварительное разрешение на использование POW! под GPL, но непонятно, распространяется ли это и на компилятор (он написан третьей стороной), сейчас пытаюсь выяснить.
5.) другие варианты

варианты 1-3 возможны только если в команде будет хотябы 2-3 профессионала, которые возьмут на себя руководство проектом и написание наиболее сложных частей, в противном случае эти варианты бесперспективны.

вариант 4 - поначалу можно вообще в компилятор не лезть, а, не особо вчитываясь в лицензию, написать некторое к-во. библиотек общего применения и сделать привязки к солидным библиотекам на С (например gtk2, icu, и т.д.) с помощью которых можно создавать более-менее нормальные программы, чтобы привлечь побольше пользователей. Когда/если количество пользователей превысит некую критическую отметку, всей толпой можно будет написать компилятор совместимый с POW (думаю, к тому времени среди пользователей появятся и профессионалы, заинтересованные в развитии) под свободной лицензией.

под профессионалами подразумеваются опытные программисты, знающие С, разбирающиеся в устройстве компиляторов и имеющие опыт работы в команде над средними и крупными проектами.

Просьба к потенциальным участникам проекта высказать свое мнение по всем представленным пунктам, а также сообщить свой профессиональный уровень и в разработке каких частей они хотят/могут поучаствовать. Это нужно для оценки того, какой объем работ мы совместно потянем (если сойдемся по основным пунктам техзадания).

Просьба к потенциальным НЕучастникам проекта воздержаться от комментариев.

Мнение - уже высказал.

Профессиональный уровень - самоучка, программирую между чаем и делом, ничего большого и страшного не писал, в основном по мелочи, более-менее ориентируюсь в WinAPI, разбираюсь в Юникоде (писал библиотеку для преобразования между различными его представлениями).

Могу поучаствовать в написании библиотек/привязок, под чьим нибудь руководством могу поработать и над какими-либо частями компилятора не связанными с железом (ассемблер и машинные команды уже совсем не помню).

Всё под контролем. В смысле модераторы за терминалами не спят.
Было предложение об поддержке экспорта AST в компиляторе. Что-нибудь такое делать в своем компиляторе будете? Извините, друзья, но пока не заявлено о создании группы по общему компилятору буду использовать этот термин для определенности.

А мне надо чтобы в BlackBox специальная кнопочка была так, чтобы нажал на неё и программа написанная (и уже отлаженная) на Компонентном Паскале автоматически превратилась в программу написанную на Си. Просто заказчики требуют на Си, а мне на нём писать не нравится.

Резонно.
И желательно всем комплектом модулей сразу...

oo2c ?

oo2c - там оберон, а я на обероне не пишу ничего, я на Компонентном Паскале под Блэкбокс.

AST это abstract syntax tree? Как я уже писал, я не силен в теориях, поэтому вопрос не ко мне, по крайней мере, не на данном этапе проекта (которого еще нет).

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

Вопрос только -- а так ли это нужно? Не проще ли просто перекомпилировать нужные модули, тем более что время компиляции обероновских модулей близко к нулю, а новые версии трансляторов обычно имеют новые дополнительные оптимизации и исправления всяких ошибок, так что перекомпилировать каждый раз модули становится просто выгодно...

ЗЫ. А микроконтроллеры я упомянул просто потому, что любители микроконтроллеров просто жаждут получить в свои руки Оберон... :о) Хотя странно, что при этом они ничего для этого не делают... :о))

Ага, ну это Вы привыкли к Хаскелям всяким... У Питона вон и правда, от версии к версии как-то 100 с лишним багов исправили. Потому что конструктивную простоту не хотять блюсти, проще на каждый баг коммюнити фичей какой-нибудь задобрить

Вы так говорите, как будто бы в Блэкбоксах всяких вообще нет ни проблем, ни багов... то-то постоянно всякие патчи выкладываете... :о))

Русификация - отдельный бальной мозоль, что Вы хотите
В компиляторе ББ ошибок не замечалось. И падений самого ББ не наблюдалось, ни одного разу на моей памяти (а это почти 3 года каждодневной эксплуатации).