Создание кросскомпилятора языка Оберон для Z80

[Oleg N. Cher]

Шаблоны, это когда компилятор пишет за тебя обертки над list. Вот у вас в статье приведен код, на Си++ он был бы "list<longint>".

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

Мне Оберон-2 видится как необходимый минимум, на который можно насадить сверху любые надстройки, добавить нужные возможности. И шаблоны, и всё, что понадобится. Но это другая языковая база, свободная от многих недостатков Си, Си++, Си#, Java и даже Ada и Delphi. Хотите на эту тему подискутировать? Пожалуйста. Только вначале перечтите ветку http://zx.pk.ru/showthread.php?t=18336, а то устал каждому одно и то же объяснять. А ещё лучше прочтите ссылки в начале этой ветки форума: http://zx.pk.ru/showthread.php?t=18418, может отпасть много вопросов и сомнений.

У меня такой вопрос:

1. В конце процедуры, например, "add" есть запись "END Add;", поймёт ли он просто "END;" ?

Нет. И это сделано затем, чтобы было легко различимо, где конец цикла/ифа, а где более глобальный конец процедуры. Меня в Си бесит, что одна и та же скобка } может закрывать всё. Володя Мутель даже придумал в таких случаях её удваивать, но это хак, согласитесь.

void fn (void)
{{
  if(...)
  {
  }
}}

2. Красным выделю вариант. Меня интересует поймёт ли компилятор ?

Думаю, Вирт и сам понял, что эти BEGIN пора сокращать. В языках Оберон и Модула BEGIN пишется только в начале процедур (и в секции инициализации модуля).

3. Как компилятор относится к регистру в тексте ? Могу ли я объявить процедуру Большими символами, а вызывать её маленькими ?

Регистр обязательно важен, как и в Си, и я считаю, что это ценно, потому что в Паскаль-программах часто пишут переменные, типы и процедуры как попало, смешивая регистр безо всякой системы. Оберонщик Саша Ильин выработал полезные соглашения для программирования, которые позволяют понять, константа это или переменная, не заглядывая вверх по тексту программы, ну и ещё некоторые полезные возможности. См. ссылку: http://forum.oberoncore.ru/viewtopic.php?f=29&t=3892

Тогда гипертрофируя твою идею все языки программирования должны компилиться с С? Не глупо ли плодить промежуточные уровни? Компилить надо только в ASM.

А почему не сразу в машинный код? Асм тоже промежуточная стадия. Кстати, bigral, Вирт тоже против промежуточных уровней. См.статью "Хорошие идеи – взгляд из Зазеркалья": http://citforum.ru/programming/digest/wirth/

Отвечаю на вопрос, зачем там Си. Компилятора Оберона для Z80 нету, а разрабатывать проги для ZX хотелось попробовать, и чтобы кодогенерация была хорошей.

Придёт время, от SDCC в этой связке можно и избавиться. Но нужно, обязательно нужно: заинтересовать сообщество, совместно наработать библиотеки и достичь концептуальной ясности того, что предстоит реализовать. Поэтому работающий макет через Си – лучше, чем несуществующий Оберон для ZX, действительно.