Компилятор Oberon-07/11 для x86 Windows

[VladimirV]

Всем участники форума!

Немного о себе. Программист микроконтроллеров. Работаю с AVR, MSP430, ARM STM32 в проектах, которые передаются на производство и выпускаются для продаж на рынок. Языки программирования: ASM, С, C++ (консольные утилиты),  FORTH и др. На С использую RTOS и собственный стековый язык программирования для CAN-шин автомобилей.

Много времени назад в режиме самообразования учился писать компилятор. И, конечно, наследие Н. Вирта Pascal, Modula-2, Oberon. С глубоким погружением изучал встречиЮ когда  большое турне Н.Вирт проводил по России (2005). Наконец-то удалось купить книгу
1.  Никлаус Вирт, Пер.: Е. Борисов, Л. Чернышов, Построение компиляторов (+ CD-ROM) // [текст] .- Изд. ДМК Пресс .- 2010 г.- ISBN 978-5-94074-585-3, 0-201-40353-6;

Искал компиляторы на Modula-2 и, конечно, "прикипел" к проекту Андреева Андрея Юрьевича "Компилятор "Странник" ( Модула-2(Оберон-2), Си(Си++) - http://home.perm.ru/strannik/

 В компиляторе Компилятор Oberon-07/11 хотелось бы добавить ARM.ob07 для генерации целевого кода для ARM STM32.

Теперь первый вопрос.
Для компилятора Oberon-07/11 есть исходные коды. Однако при импорте SYS сама реализация SYSTEM связи с операционной системы спрятана в 'Compiler.exe'.

Я правильно понял?

Второй вопрос.

Есть ли смысл добавить в компилятор "Странник" реализацию Oberon 07?

[ilovb]

SYSTEM - это псевдомодуль. Реализацию нужно смотреть в компиляторе, да.
Думаю, начинать смотреть нужно тут: https://github.com/ilovb/Oberon07akron1/blob/master/Source/Compiler/DECL.ob07#L1397


Странник... не знаю... какой от него толк может быть? Автор его давно забросил.
Какой смысл добавлять туда O07?

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

[Valery Solovey]

Есть ли смысл добавить в компилятор "Странник" реализацию Oberon 07?

Смысл - это понятие, привязанное к цели.

Если цель - расширить свой рабочий инструмент Обероном, то да - имеет смысл, раз Вы собираетесь им пользоваться. Или если разработка ведётся ради удовольствия.

Если цель - увеличить популярность Оберона (или Странника), то смысла особого нет: сообщества этих проектов маленькие, увеличить одно из них за счёт другого получится лишь чуть-чуть.

[VladimirV]

Смысл - это понятие, привязанное к цели.

Если цель - расширить свой рабочий инструмент Обероном, то да - имеет смысл, раз Вы собираетесь им пользоваться. Или если разработка ведётся ради удовольствия.

Если цель - увеличить популярность Оберона (или Странника), то смысла особого нет: сообщества этих проектов маленькие, увеличить одно из них за счёт другого получится лишь чуть-чуть.

Цели:
1. В "Страннике" много его имеется: редактор (причём автор сделал его не зависимым от языка программирования), три языка программирования, справочна я система, русско-язычные ключевые слова для Си, Modula-2, Pascal, встроенный ассемблер x86, примеры и компактная реализация.
2. В "Странник" встроена возможность отлаживать программный код в DBG.
3. Хочется выделить в "Страннике" на отдельные части компилятор я зыков, редактор, ассемблер и генерация целевого кода. А так же вернуться к стандарту. Автор внёс изменение в описание языков и отошёл от реуомендованных стандартов.
4. Добавить OBERON-7 с целью сделать возможным запускать проект на микроконтроллерах.
5. Добавить встроенный ARM-ассемблер и генерацию для ARM  процессоров.

Здесь многоговорилось о высокой надёжности OBERON. Однако ведь надёжность определяется операционной системой, где собственно и запускается код.

А какая надёжность у операционной системы OS Oberon?

[Geniepro]

А какая надёжность у операционной системы OS Oberon?

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

Вот в A2, вроде бы, с этим получше, тут Kemet может подробнее рассказать, наверное...

[valexey_u]

А какая надёжность у операционной системы OS Oberon?

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

Строго говоря, там и кооперативной многозадачности нет (то есть там нет ничего похожего например на fiber'ы - нет сохранения контекста).

А безопасность достигается чисто средствами языка. То есть если не пользовать SYSTEM, то порушить что-либо довольно сложно.

[Geniepro]

А так же вернуться к стандарту. Автор внёс изменение в описание языков и отошёл от рекомендованных стандартов.

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

[VladimirV]

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

У него другая идея была. Он (Андреев А.Ю.) искал абстрактное синтаксическое дерево, большая часть которого не зависит от конкретного языка. И сделал это!

Каталог st_sm_src

Код: [Выделить]


//СТРАННИК Модула-Си для Win32
//Модуль PRE (модуль межязыкового перевода)
//Файл SMPRE.M

implementation module SmPre;
import Win32,Win32Ext,SmSys,SmDat,SmTab,SmGen,SmLex,SmAsm,SmTra,SmTraC;

procedure preNextLex(var S:preStream); forward;
procedure preGetLex(var S:preStream); forward;

 

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

Вопрос участникам: Есть ли готовый плагин Oberon-07 для подсветки в  NotePad++ ?

[Valery Solovey]

Здесь многоговорилось о высокой надёжности OBERON. Однако ведь надёжность определяется операционной системой, где собственно и запускается код.

Нет. Надёжность языка определяется характеристиками языка, надёжность ОС определяется характеристиками ОС. Всё опять же сводится к целям: у ОС они свои (опреление доступа к ресурсам), а у языка программирования - свои.

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

[Valery Solovey]

А какая надёжность у операционной системы OS Oberon?

Весьма эфемерная -- кооперативная многозадачность без защиты памяти процессов.

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

[Geniepro]

Есть ли смысл добавить в компилятор "Странник" реализацию Oberon 07?

Как пишет сам автор Странника:

При реализации классов и объектов за основу взяты механизмы языка Оберон-2, ставшего фактическим стандартом реализации ООП в Модуле. При этом оператор WITH сохранил свою семантику (т.е. по-прежнему предназначен для работы с записями, а не для проверки типа объекта). Поскольку Модула-2 мощнее Оберон-2 во всем, что не касается ООП, название языка сохранено, хотя реализацию Модулы-2 в Страннике можно смело считать надмножеством языка Оберон-2.

Так что непонятно, какой смысл в добавлении Оберона-07 в этот набор компиляторов...

[VladimirV]

SYSTEM - это псевдомодуль. Реализацию нужно смотреть в компиляторе, да.

Не нашёл в файле Compiler.ob07 реализацию процедур для SYSTEM, тем более в начале объявляется импорт:
IMPORT RTL, DECL, SCAN, UTILS, X86, SYSTEM;

И в других файлах нет реализации SYSTEM.

[akron1]

Как вам должно быть известно, в обероне есть "стандартные" процедуры -- INC, LSL, LEN... Эти процедуры не имеют исходного кода и обрабатываются компилятором как обычные операторы и операции. Как правило такие процедуры не вызываются а подставляются. Для компилятора нет принципиальной разницы между "стандартными" и SYSTEM-процедурами. Если компилятор встречает идентификатор "стандартной" или SYSTEM-процедуры, то вызывается процедура StFunc или StProc модуля Compiler, где происходит разбор параметров и генерация машинного кода.
Что касается генерации машинного кода для ARM, то сейчас это бесперспективно. Дело в том, что модуль Compiler (синтаскический разбор операторов и выражений) и модуль DECL (синтаксический разбор объявлений) тесно связаны с модулем X86. По-хорошему, компилятор должен сначала генерировать промежуточный (машино-независимый код), а затем транслировать его в машинный. То есть, модули Compiler и DECL обращаются к модулю генерации промежуточного кода, а потом трансляцию промежуточного кода в машинный выполняет модуль X86 или ARM. А пока, увы... У меня не было цели сделать что-то хорошее, просто "лишь бы работало", поэтому получилось так...

[VladimirV]

Если компилятор встречает идентификатор "стандартной" или SYSTEM-процедуры, то вызывается процедура StFunc или StProc модуля Compiler, где происходит разбор параметров и генерация машинного кода.

Что касается генерации машинного кода для ARM, то сейчас это бесперспективно.

модули Compiler и DECL обращаются к модулю генерации промежуточного кода, а потом трансляцию промежуточного кода в машинный выполняет модуль X86 или ARM. А пока, увы... У меня не было цели сделать что-то хорошее, просто "лишь бы работало", поэтому получилось так...

Автору реализации компилятора Oberon-07 for x86 - огромная благодарность за вклад просветления прогрограммистких умов! Это важная, очень важная задача иметь возможность одной головой "охватить" весь цикл создания целевого кода для процессора.

Благодарбю за подсказку о процедурах StFunc или StProc. Теперь буду смотреть и понимать как SYSTEM связан с модулем модуля Compile.ob7.

Вы утверждаете, что "генерация машинного кода для ARM, то сейчас это бесперспективно" Как Вы пришли к такому поспешному и неверному выводу!?

Программирую микроконтроллеры с прошлого века, а именно 1987 года: 8080, Z80, 8051, Atmega161, AT91Sam3, PIC18, MSP430, STM32. Начинал с ассемблера. Далее желанный Си.  В интернете сейчас, словно лампочек на ночном небе, проектов для микроконтроллеров. И, нет НИ КАКОЙ ПЕРЕНОСИМОСТИ исходных кодов из проектов даже на Си! Каждый новый проект вынужден делать несколько месяцев. Иногда сроки проекта пересекают период больше года. Медленно. Очень медленно. Рукодство часто смотри косо на программеров. Переносимости практически нет, а значит  опять строить проект приходтся с нуля с пустой тратой драгоценного времени.

Мировое произвоство микроконтроллеров растёт, например в прошлом году продажи ARM 32-разрядные  выросли на +12%. И для каждого чипа нужна "прошивка" и реализацию потребительских задач. Поэтому-то имеем дефицит программистов. Не успеваем выполнять "хотелки" руководителей и удовлетворять на рынке потребителя...

А вот Oberon 07 для x86 - это тупичок. В качестве обучающей системы - согласен. В качестве платформы для генерации целевого кода для ARM - согласен. Но использовать Oberon 07 для создания приложений в x86 и продавать - тупичок. Для Windows, Linux имеется множество зрелых IDE и целевых языков программирования... Н. Вирт с сотоваришами так и не смогли вывести на массовый рынок среду компиляции Modula-2, Oberon-2, Oberon-7.
 
Как подправить Ваш проект Oberon-07, чтобы выводить листинг машинного кода для x86?

[valexey_u]

А вот Oberon 07 для x86 - это тупичок. В качестве обучающей системы - согласен. В качестве платформы для генерации целевого кода для ARM - согласен. Но использовать Oberon 07 для создания приложений в x86 и продавать - тупичок. Для Windows, Linux имеется множество зрелых IDE и целевых языков программирования... Н. Вирт с сотоваришами так и не смогли вывести на массовый рынок среду компиляции Modula-2, Oberon-2, Oberon-7.

Если хочется платный Oberon-компилятор для армов (точнее микроконтроллеров армовых), то он уже есть: http://www.astrobe.com/

Так что создание платного компилятора для ARM-микроконтроллеров - это тоже тупик и не интересно :-)