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

[valexey_u]

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

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

Ну и какие преимущества у Оберона (именно у Оберона, не у Оберона-2) перед скажем Модулой-2? ООП в мире микроконтроллеров не нужно. Да и в том виде в котором оно есть в Обероне, оно, скажем так, более-менее хорошо смотрится только в ОберонОС. На тех задачах. Во всем остальном Оберон слабее Модулы-2. В конце концов Оберон изначально спроектирован под среду исполнения со сборщиком мусора, в отличае от модулы. И изначально Оберон - он для рабочих станций (прошлого века правда, но это не важно), с кучей памяти и толстым процессором, а не встроенки.

Так почему Оберон для микроконтроллеров а не Модула-2?

PS. Сам я Оберон знаю много лучше модулы. Ну и поскольку я вложил в него довольно много времени и сил, испытываю к нему некую симпатия, но на вещи нужно смотреть таки трезво.

[Valery Solovey]

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

Как использовать Оберон в маленьких контроллерах - не очень понятно. На каждый контроллер можно выделить по модулю и взаимодействие модулей может символизировать взаимодействие контроллеров. Но я не думаю, что несколько контроллеров на одном устройстве - это частый случай. Ещё, можно писать по модулю на разные модели контроллеров и эти модули будут являть собой микро-ОС, которые делают общение с контроллером вмеру однородным (эдакие подсистемы Host). Тогда понятно, как можно присобачить абстрагирование (ООП), но возникает проблема с написанием оптимизирующего компилятора, чтобы программа укладывалась в тайминги и помещалась в память.

[VladimirV]

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

1. Никлаус Вирт, Проектирование системы с нуля. // [текст].-М.-Журнал Мир-ПК, №9, 2002 г. - http://oberon2005.oberoncore.ru/paper/scratch.pdf

Система Oberon представляет собой однопользовательскую однопроцессную
многозадачную систему, ориентированную на рабочую станцию. Она разрабатывалась не на базе уже существующего программного обеспечения,
а фактически с нуля. В этой статье освещается последовательность шагов проектирования, которая постепенно привела к построению полной системы. Данный проект в значительной степени использовал такой прием, как раскрутка
(bootstrapping), который применялся как по отношению к разработке компилятора, так и по отношению ко всей системе в целом.

Кратенько и точно обосновываются преимущества Оберона (именно у Оберона, не у Оберона-2) перед скажем Модулой-2...

"... В конце концов Оберон изначально спроектирован под среду исполнения со сборщиком мусора, в отличае от модулы..."

К компилятору это никак не относится. Это реализация OS Oberon, т.е. надстройка для конкретной реализации.

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

Oberon "поселили" на компьютере LILITH:

состоял из четырех процессорных наборов Am2901, выполненных на плате, а
не в кристалле (bit-slice). Частота его была 7 МГц, длина слова и ширин а шины 16 разрядов. Оперативная память многопортовая (128 Кбайт). Дисплей, как и
в случае Xerox Alto, был вертикальным, размером 15" (592х768 точек), в качестве диска использовался Honeywell-BullD-120 емкостью 10 Мбайт. Ну и, конечно, имелась трехкнопочная мышь.

Наш случай для ARM.   Прошлый век перебрался в один кристалл кремния.

"...PS. Сам я Оберон знаю много лучше модулы. Ну и поскольку я вложил в него довольно много времени и сил, испытываю к нему некую симпатия, но на вещи нужно смотреть таки трезво...

Нас уже двое.

Установил Astrobe Oberon for Cortex-M3 Microcontrollers  (Astrobe website at http://www.astrobe.com/for details of what is included in each edition.) и на днях испытаю примеры Oberon-07 на кремневом камне ARM LPC.

[Romiras]

http://www.ocp.inf.ethz.ch/forum/index.php?topic=766.0 - Sources for AOS Oberon for ARM, or ARM Compiler

http://matthias.dnsdynamic.com/oberon/doku.php?id=alo - ARM Linux Oberon

[Romiras]

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

За счёт каких качеств Оберона код должен получиться переносимым, в отличие от Си?

[VladimirV]

За счёт каких качеств Оберона код должен получиться переносимым, в отличие от Си?

Процесс создания полезного приложения:

(1) "Програмист" -> "Текст программы" -> "Oberon" -> "C" -> "ASM" -> "Машинный код камня".

! "Oberon" -> "C" - перевод в код Си - это как стихи А. Пушкина перевести на зулу́сский язык.  Тогда уж лучше писать просто на Си, т.е. "нативно" в рамках стандарта C89 или C99.

(2) "Програмист" -> "Текст программы" -> "Oberon" -> "ASM" -> "Машинный код камня".
Этот вариант уже интереснее. Можно быстро адаптировать фонд исходных кодов на языке Oberon. Сам синтаксис не меняется, а лишь меняется реализацию перевода синтаксического дерева в целевой код микроконтроллера.

(3) "Програмист" -> "Текст программы" -> "Oberon" -> "Машинный код камня".
Этот вариант предложил Н.Вирт и реализовал в системе Oberon. Именно это и позволяет получить однопроходный вариант компилятора с языка Oberon.

Самый компактный синтаксис у Oberon. Можно построить вокруг и статические анализатора кода, и хранение исходного кода проекта не в текстовом виде, а в виде  объектов синтаксического дерева с атрибутами...

"Программа — не текст, а набор конструкций".

Отправляю Вас почитать отличный материал автора компилятора "Странник".

1. Андрей Андреев, Эволюция современных языков программирования. // [текст].-М.- "Мир ПК ".- № 03, 2001. - http://www.osp.ru/pcworld/2001/03/161246/

"...
Большинство алгоритмических языков программирования, таких как Си и Паскаль, были созданы на рубеже 60 и 70-х годов. Иными словами, их возраст (за исключением Java) перевалил за третий десяток, что для компьютерной индустрии срок немалый. Они старше Internet, Windows да и собственно ПК не менее чем на десятилетие. Стоит отметить, что новые языки не переставали регулярно появляться, однако ни один из них не задержался в практике программирования, хотя приносимые ими идеи становились достоянием известных языков (как это произошло с объектно-ориентированным программированием).
..."

 

[VladimirV]

Получился "каменный цветок"

1. Заехал в питерский "Чип и Дип" и приобрёл за 1040 руб. отладочную плату:
LPC-P1343 - отладочная плата на базе микроконтроллера LPC1343 с ядром Cortex-M3 и тактовой частотой до 72 МГц. Микроконтроллер имеет 32 кБ Flash-памяти и 8 кБ ОЗУ.
2. Скачал и установил AstrobeM3EvalSetup.zip
3. При установке на Windows XP Astrobe Oberon for Cortex-M3 Microcontrollers попал в каталог: 'C:\Program Files\AstrobeM3 Evaluation Edition' Внимание!  Этот путь не работает!!   

При попытке сделать Build примеров в Astrobe (как в Starter M3 так и в Eval)
выходит ошибка переполнения

Переместите каталог Astrobe из каталога "Мои документы" в другое место, чтобы в путях не было кириллицы.
4. Порадовала реализация программирования микроконтроллера. При замыкании переключателя SW через usb платы windows xp увидел как flash-диск. Просто на него нужно положить bin-файл собранного компилятором (у меня пример Blinker.bin).
5. Исправил вывод импульсов на другой пин микроконтроллера там где светодиод.

Исходный код примера на Oberon-07  для камня LPC1343: 

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

IMPORT Main, MCU, SYSTEM, Timer;

PROCEDURE Run();
CONST
  (* led connected to pin P0.7 *)
  ledBit = {0};
VAR
  direction, data: SET;
BEGIN
 
  (* Set led pin as output by setting the direction bit *)
  SYSTEM.GET(MCU.GPIO3DIR, direction);
  SYSTEM.PUT(MCU.GPIO3DIR, direction + ledBit);
 
  WHILE TRUE DO
    SYSTEM.GET(MCU.GPIO3DATA, data);
    SYSTEM.PUT(MCU.GPIO3DATA, data + ledBit);
    Timer.MSecDelay(500);
    SYSTEM.GET(MCU.GPIO3DATA, data);
    SYSTEM.PUT(MCU.GPIO3DATA, data - ledBit);
    Timer.MSecDelay(500)
  END
END Run;

BEGIN
  Run()
END Blinker.
ТЕСТ - УСПЕХ!

[VladimirV]

Дисассемблер online для процессоров

Решил дисассемблировать BIN-файл для ARM LPC1343.

1. Онлайн дисассемблер машинного кода. //[электронный ресурс] .- http://onlinedisassembler.com/odaweb/#view/tab-assembly/offset/00000240

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

[valexey_u]

Я бы рекомендовал создать отдельную тему про Оберон. ARM и микроконтроллеры. Текущее обсуждение более не имеет прямого отношения к x86 компилятору Оберона.

[Geniepro]

VladimirV, так Вы так и не ответили, почему программы на Обероне-07 будут более переносимы, чем на сях.

В сях проблема с переносимостью, в основном, это всякие языковые расширения -- распределение переменных в разных областях памяти типа data|idata|xdata, обработчики прерываний. В обероне эта же проблема останется -- в описании оберона ничего не сказано о том, как распределять переменные, прерывания, значит в разных реализациях транслятора это будет сделано по разному (как, собственно, и в сях). В этом плане Ада предпочтительнее -- там есть необходимые для этого средства.

Кроме того, в сях хотя бы есть указание разрядности типов данных (в хедер-файле limits.h), правда, сомневаюсь, что им реально пользуются, ведь то, что необязательно -- почти никогда не используется.
В Обероне-07 с этим тоже проблема -- разные реализации для разных микроконтроллеров будут по разному отводить память под тот же INTEGER -- где-то это будет 16 бит, где-то -- 32 и тд.

Так и как в таких условиях гарантировать переносимость программ на обероне?

[valexey_u]

Кроме того, в сях хотя бы есть указание разрядности типов данных (в хедер-файле limits.h), правда, сомневаюсь, что им реально пользуются, ведь то, что необязательно -- почти никогда не используется.
В Обероне-07 с этим тоже проблема -- разные реализации для разных микроконтроллеров будут по разному отводить память под тот же INTEGER -- где-то это будет 16 бит, где-то -- 32 и тд.

Так и как в таких условиях гарантировать переносимость программ на обероне?

Есть ещё stdint.h - и этим реально пользуются. Типы вроде uin8_t, uint16_t и так далее. Это резко повышает переносимость. Но в Аде конечно лучше.

[VladimirV]

VladimirV,
(1) почему программы на Обероне-07 будут более переносимы, чем на сях.

(2) В сях проблема с переносимостью, в основном, это всякие языковые расширения -- распределение переменных в разных областях памяти типа data|idata|xdata, обработчики прерываний.

В обероне эта же проблема останется

(3) -- в описании оберона ничего не сказано о том, как распределять переменные, прерывания, значит в разных реализациях транслятора это будет сделано по разному (как, собственно, и в сях). В этом плане Ада предпочтительнее -- там есть необходимые для этого средства.

(4) В Обероне-07 с этим тоже проблема -- разные реализации для разных микроконтроллеров будут по разному отводить память под тот же INTEGER -- где-то это будет 16 бит, где-то -- 32 и тд.

Так и как в таких условиях гарантировать переносимость программ на обероне?

(1)*

Что я ожидаю от исходного кода на языке программирования?

Должна работать в других проектах с помощью "import" и копии реализации драйвера переферии или библиотеки.  На Си такое не получается. Заголовочные файлы ссылаются на зависимые библиотеки компилятора. Различные версии Си не совместимы. Часто фирмы поставляющие компиляторы немного изменяют синтаксис и код требует большой ручной правки, чтобы перенести в проект. 

Я за строгий и очень компактный синтаксис  Oberon.  Тогда всё что на нём написано может быть быстро перенесено в другие проекты.

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

(3)* Как раз это и правильно. Важно, чтобы конструкции Oberon программы компилировались и просто работали в проекте. Пусть реализация спрятана от программиста, который реализует алгоритм. Было бы желательно иметь несколько реализаций на ассемблере, когда по интегральныи оценкам качества можно выбирать лучший фрагмент кода, который и будет использоваться компилятором Oberon.

(4)* Так и пусть переводит. Целевая задача не экономить биты, а получить сразу работающее приложение для целевого процессора.

(5)* Строгость и дисциплина. Oberon же, как я понял, имеет элементы объектно-ориентированного программирования.

Кочно это моё не окончательное мнение. Нужно построить какую-нибудь достойную задачу и тогда станет ясно про сильные и слабые строны Oberon для создания приложений.
 

[Valery Solovey]

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

Раз производители изменяют язык у которого есть стандарт, то добавить своих расширений в Оберон им тоже никто не помешает. Правда, самому делать нужный компилятор Оберона проще: синтаксис слегка меньшего объёма и нет стандартной библиотеки, которая в си создавалась не под микроконтроллеры.

[Geniepro]

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

Раз производители изменяют язык у которого есть стандарт, то добавить своих расширений в Оберон им тоже никто не помешает. Правда, самому делать нужный компилятор Оберона проще: синтаксис слегка меньшего объёма и нет стандартной библиотеки, которая в си создавалась не под микроконтроллеры.

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

[Valery Solovey]

Тоже мне проблема... Будут распространять нестандартную Аду.