OberonCore

Просто дело в том, что это отдельное требование к тому как он должен быть реализован, а не к нему самому.Из того что было перечислено не вытекает.
Нечто вроде компилятора?

Кроме front-end к gcc другие standalone компиляторы сейчас мало интересны, тем более, что они есть. Про "загружабельность/выгружабельность модулей аля классическая Оберон-система или ББ" можно забыть сразу... ну почти...

Хорошо, если посмотреть под другим углом - интерпретатор не подойдет? Быстрее вроде будет сделать...
Для ускорения работы тексты программ можно перегнать в байт-код на конечном этапе.

"Шаг вперёд, два шага назад" (с) Ленин

После этого на определённом этапе возникнет потребность сделать JIT и т.д. какой смысл огород городить? GCC интересен прежде всего своей страшной распространённостью и приличным количеством целевых платформ...

Да, я понимаю, что машину виртуальную можно подо все платформы подогнать. Вот только смысла в этом никакого нет...

Это в общем ясно, неясно пока какие шаги Вы планируете предпринять, чтобы этот вопрос прояснить.

Диалог глухих что называется. Ваша самоувереность негативно влияет на тон дискуссии, многоуважаемый Борис.

Вобщем-то... не хотелось бы бежать впереди паровоза, но gcc-компилятор может облегчить построение Оберон-рантаймов под разными платформами...

Спасибо. Мне пока психоаналитик ещё не требуется.

Моя точка зрения: другие виды новых компиляторов Оберонов, кроме front-end к gcc сейчас не рентабельны (для ИТ-промышленности).

Это сугубо моё мнение.

Причем здесь то о чем я спросил у Алексея? Ну да ладно. Если Вы спрашиваете о множестве рантаймов чем наличие его у gcc может помочь? ( всё равно их нужно будеть переделывать если задумали делать нечто оригинальное).

Уважаемый GUEST, это было общее замечание по контексту.

Спасибо, но контекст моего вопроса не совсем отвечает Вашему суждению о нем.

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

Извините, я не очень понял вопрос. Имеется ввиду изучение внутренней структуры gcc & Oberon & BB с целью выяснения возможности сохранения загружабельности/выгружабельности в случе front-end'a к gcc?

На микроконтроллерах свет клином не сошелся. Для не микроконтроллеров наличие такой возможности в языке это очень большой плюс. Не надо городить для своего приложения каждый раз велосипед в виде плагин-системы. Получаем (скорее всего) переносимость бинарных модулей (не использующих напрямую системно-зависимые функции) между разными ОС (но одинаковыми архитектурами). Это просто ОГРОМНЫЙ плюс.

Но если окажется (а оно скорее всего окажется) что реализовать такую фичу для реализации компилятора в виде front-end'a к gcc будет невозможно либо очень сложно (дорого по времени и усилиям), то ну её нафиг. Лучше компилятор без этой фичи, чем отсутствие компилятора вообще.

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

Не понял без какой.

Динамическая загрузка-выгрузка модулей.

Вы говорили об изучении внутренней структуры gcc. Как же её изучение может помочь в выяснении этой возможности если её там нет. Следует смотреть там где она уже представлена, по-моему. И переносить наряду с прочими возможностями Oberon в будущий компилятор. Если его действительно кто-то уже планирует делать.

Ещё одно абстрактное замечание : в принципе, динамическая загрузка это не проблема компилятора, а проблема рантайма. Никто не мешает написать динамический рантайм так, чтобы он грузил стандартные объектные .o от gcc. Так что...