OberonCore

Приятно слышать.А кто это мы? Сколько эта тема ранее ни поднималась, никогда никто сильной заинтересованности ни проявлял. Можете убедиться сами.

Собственно говоря, смысла делать слимы без бэк-энда нету. Разве что разобраться с форматом надо до написания фронт и бэк эндов.
Сейчас у меня скорее общее впечатление о способе хранения предложенном Францем. И медленно ползущее штудирование книжки Compiler Construction Вирта.

Это не совсем верно.


Наверное, можно было бы и стандартные. Есть в этом определённые достоинства. Но и недостатки тоже.
Вот несколько навскидку.

• Для каждой ОС надо поддерживать свой объектный формат.
• Степень стандартности DLL у разных ОС разная: в Windows - встроенная в ядро, в Linux это уже надстройка, а, скажем, в Minix их вообще нет.
• Линковать стандартные DLL трудно.

Правда, обероноские объектники тоже не очень удобно линковать из-за того, что их стуктура сильно отличается от бинарников ОС.

Согласен.
Есть ещё вариант, как с bpl (или как там бибилиотеки компонент Delphi называются):
когда используется DLL, но имеющая определённый интерфейс - через вызовы функций этого интерфейса можно получать доступ к описаниям сущностей в спец. формате...

Я о том, что экпортируются не только "точки входа в процедуры", но "точки входа в данные".

С минимальной не пойдет. У Франца слишком жесткая привязка к языку.

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

Разве? Я пока из принципиального только связанные процедуры заметил. Ограничения же (типа экспорта для реализации), думаю, можно хранить в файле отдельно от самого sde придставления.

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

А можно кратко просветить что есть "четверки" и SSA? Да и slim явно предполагают отсутствие виртуальной машины.

Мы, это те, кто занимается модернизацией ББ. В частности Метасистемы.
Да, тема раньше поднималась, но мы не можем всё охватить сразу. Проблемы решаются постепенно. К этим задачам постепенно подходим вплотную, поэтому если кто-то выполнит хотя бы часть работы, это уже будет очень хорошо.

Нельзя. Слимы сохраняют полную информацию об исходном тексте. Того же самого можно добится разьве только используя zip или rar .

В слиме даже комментарии и отступы хранятся?

А разве слим и "четвёрки" вещи взаимозаменяемые? То есть, "четвёрки" нельзя использовать в слимах?

Моё ИМХО: лучше пока ничего не менять, а просто нормально документировать формат OCF (хотя бы в неофициальном стиле PE-дока от Hard Wisdow - без формальной нотации, но с таблицами и подробными пояснениями). Может быть, поучаствую даже в распутывании этой "криптограммы".

Нет. Комментарии и форматирование теряется.

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

про инферно я упомянул в том смысле что его ВМ не традиционная, не стековая.
а трехадресная многорегистровая. и это очень напоминает как раз внутреннее
представление четверками в компиляторе.

2batyr Авторы расскажут лучше меня, поищите в интернет внутренние представления программ в компиляторах.

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

Имеется в виду сохранение полной высокоуровневости семантики операций! Именно - сАмого высокого уровня - в понятиях исходного текста.
А - не "укращшательств".
"Четвёрки" а ля из Инферно - такой информации содержать не будут (даже если и "группировать их особым образом"). Они, как и любой "байт-код" - всего лишь оттранслированный набор операций (хотя бы и абстрактного "процессора") с более низким уровнем "смысла операций" однозначного представления 1-в-1 у вас не получится, а, значит, смысл ваших выражений на языке высокого уровня уже будет разбит и преобразован во что-то другое...

slim универсален, в отличие от всяких 4-к и прочего.
- фронт-енд строит синт. дерево и это дерево фактически и есть slim. по нему загрзучик бэк-енд генерит код непосредственно под конкретную платформу. Если язык прост (Оберон), то реализовать бэк-енд с нуля надо 3-4 мес. одному человеку (прикидки Франца).
- фронт-енд строит (получает в процессе разбора) дерево, бэк-енд выдает код некоей виртуальной машины. Загрузчик должен преобразовать этот код под конкретную платформу. Всегда найдется (или появится) платформа, сильно отличная от виртуальной машины и от неё придется отказаться.

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