OberonCore

Где-то в районе 3-6 человеко-месяцев, в зависимости от того, что в этот front-end нужно впихнуть. Только компилятор Оберона можно написать быстрее.

Собственно, большая часть времени уйдёт не насам компилятор (это достаточно просто), а на стыковку с gcc.

"Скинуться" - это всё равно достаточно приличная сумма. В принципе, можно "скинуться", разработать на заказ и отдать сообществу в опен-соурс без дальнейшей поддержки...

Я бы хотел, чтобы Вы или AVC пояснили почему считаете это необходимым. Если не считаете то вопрос исчерпан. А он похоже исчерпан и так.

Необходимым?

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

Увы это цель Борис, а причины так ни одной и не названо.

Любители микроконтроллеров (по крайней мере семейства AVR) давно уже могли взять в руки OO2C, у которого как раз есть версия для AVR. Да и ARM'щики могли бы, наверное, связаться с Виртом с просьбой помочь -- поделиться компилятором, которых у Вирта немерянно... :о)

И кому это будет нужно? Таких неподдерживаемых и ныне забытых компиляторов... Да хоть XDS вспомните...

Главное понять куда.

Тогда назовите мне причину делать компилятор только одного языка.

1.Облегчение создания компилятора.
2.Облегчение документации к нему.

Ну... в данном случае 1) - это не аргумент вообще. Сложность многоязыкового компилятора с одной семантической базой возрастёт процентов на 10...

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

В конце концов, можно просто не развивать и не документировать неосновные ветки сразу, но иметь их внутри в "закукленном" виде.

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

Кстати, как привести Ваши с Борисом Рюмшиным оценки трудозатрат к одному знаменателю?

Смотря кто и какими методами будет писать. Моя первая оценка была для случая, если за задачу возьмётся энтузиаст(ы).

По поводу "общей семантической базы".
Такие компиляторы есть. Пример -- gcc. Основа здесь -- общее промежуточное представление кода, позволяющее использовать фронт-энды для языков с различным синтаксисом и бэк-энды для различных целевых платформ.
В случае языков Оберон, Оберон-2 и Компонентный Паскаль все проще, т.к. в принципе Оберон можно рассматривать как подмножество Оберона-2, а Оберон-2 -- Компонентного Паскаля.
Следовательно, промежуточное представление кода имеет смысл строить в расчете на КП, а ранние обероны в него нормально впишутся. (Сразу отмечу, что расхождения в разрядности между Обероном и Компонентным Паскалем серьезной помехой не являются.)
Илья Ермаков правильно говорит, что сначала можно реализовать одну версию Оберона, потом добавить остальные.

Совместимость со "сторонними" библиотеками основывается на использовании одинаковых соглашений о вызовах процедур (calling convention), т.е. того, как передаются аргументы, и, в случае процедуры-функции, того, как возвращается значение.
В случае Windows есть общепринятый способ (stdcall).
Если в calling convention все-таки будут расхождения, то обероновский модуль, представляющий интерфейс сторонней библиотеки, возьмет на себя роль "шлюза" и обеспечит согласованность интерфейсов.

Еще раз хочу подчеркнуть мысль, что главный шаг -- прояснить область применения будущего компилятора.

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

Ну, у меня интерес довольно широкий. Нужен компилятор который может собирать под x86/x64 (Windows & Linux). Под Arm и MIPS (Linux). Компилятор желательно чтобы был под GPL, рантайм был под LGPL-лицензией.

Нужна общая "стандартная" библиотека. Нужна возможность оптимизации кода компилятором. Нужна кросс-компиляция. Нужно чтобы сборка исходников использующих только стандартну библиотеку и писаных скажем под Win/x64 спокойно и без правок собралось (и заработало!) на Linux/Arm. В общем, нужен ещё один front-end к gcc. Правда в этом случае я не очень понимаю как возможно сохранить загружабельность/выгружабельность модулей аля классическая Оберон-система или ББ. Посредством специфического рантайма + доп. утилитки для генерации таких модулей?

И что будет в качестве инструментальной системы? BlackBox? Или что-то специфическое?

Для ББ придется в стандартную библиотеку пихать ещё и графику как минимум. У ББ больши-ие проблемы с невиндой. Поэтому в качестве "инструментальной системы" логично предположить произвольный текстовый редактор + консольные утилиты. Лично меня это более чем устроило бы.

Ну, можно плагин к еклипсе написать.

PS. Кстати. хорошо бы чтобы компилятор умел экспортировать синтаксическое дерево. Т.е. чтобы было возможным сделать нечто аля ASIS'a Адовского. Да и для всяких плагинов к эклипсе это бы сильно пригодилось.