Разработка программ и игр для ZX Spectrum на языках Оберон-семейства

[Oleg N. Cher]

А вот мне оберон (да и все остальные паскали) не нравится тем, что переменные процедуры нужно в отдельной секции описывать. На процедурах размером по 400+ строк, имеющих несколько десятков переменных удобнее концепция фрейма.

Вряд ли Вам щас понравится, если я начну про засратые сями и явой мозги парить, правда? То-то же.

int a = 10; // фрейм 0
if (true) {
int b = 10; // фрейм 1
}
// здесь переменные фрейма 1 уже не видны.

Надеюсь, понятно объяснил. Не совсем по науке, но суть такая.

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

PROCEDURE A;
VAR
  z, x: INTEGER; (* Это общие для "фреймов" переменные *);

  PROCEDURE Frame1; VAR a, b (* Это личные переменные "фрейма" Frame1 *)
  END Frame1;

  PROCEDURE Frame2; VAR a, b (* Это личные переменные "фрейма" Frame2 *)
  END Frame2;

BEGIN ...
END A;

Интересует возможность поюзать Оберон для работы с объектами ООП.

Оберон-2:

TYPE
  ElemType = INTEGER;
  Stack = RECORD
    a, b ... (* это внутренняя реализация, снаружи не видно – инкапсуляция *)
  END;

PROCEDURE (VAR s: Stack) Push* (elem: ElemType);
...

PROCEDURE (VAR s: Stack) Pop* (): ElemType;
(* Здесь s – это поименованный self, снова не анонимный. Это удобно *)
...

VAR
  stack1, stack2: Stack;
BEGIN
  stack1.Push(123); stack2.Push(stack1.Pop());

В Active Oberon малость посложнее, там есть милые сердцу OBJECT и SELF, но принцип в целом тот же.

А вот наследование:

TYPE
  ExtendedStack = RECORD (Stack)
    (* Запись унаследована от расширяемой записи Stack *)
    a, b, c: SomeType; (* Это дополнительные поля *)
  END;

PROCEDURE (VAR es: ExtendedStack) SomeProc1 ...
PROCEDURE (VAR es: ExtendedStack) SomeProc2 ...
    (* Это доп. методы *)

http://forum.oberoncore.ru/viewtopic.php?f=8&t=2121
http://forum.oberoncore.ru/viewtopic.php?f=29&t=2125

Я на пц обхожусь PureBasic / PHP / JS / C, на спектруме Ассемблером.
Куда логичнее перенести на спектрум, что то из перечисленного чем изучать новое.

Перенести на Спек PHP или JS? Ор-ригинально, батенька. Уже кажется Java переносили, тока 32-битность помешала. Но попробуйте, чего ж. А раз освоили PHP (и особенно JS), то Обероны пустячок, уверяю-с.

А Вы вот это видели?

ZX BASIC compiler v1.2.5, by Jose Rodriguez.
Allows you to write a BASIC program on your PC and convert it to TZX to run on your real Speccy/emulator. The compiler works in all of PC/Windows, Linux and Mac OS X.
http://www.boriel.com/software/the-z...piler/?lang=en

Z80 Advanced Forth Compiler build 8 (PC/Windows), by Dumitru Florin Gabriel.
http://www.worldofspectrum.org/utilities.html (оф.сайт не открылся)

The ccz80 language
CCZ80 v2.0.5 (PC/Windows), by Emilio Guerrero.
The ccz80 language has a syntax based on the C language and produces assembler code - an assembler is integrated in the compiler.
http://www.telefonica.net/web2/emili...z80/ccz80.html

Вобщем, осталось только Обероны освоить. И сделать компилер. Всё остальное для Z80 уже есть.

Поддерживаю создание компилятора Оберон'а для спектрума.

Oberon который чистый практически полностью ложится LL1 грамматики (там одно или два исключения, не помню уже), Active Oberon чуть хуже ложится на LL1 из за "атрибутов", но все равно на порядок лучше чем тот же С.
Значит этот язык естественным образом ложится за один проход на стековую машину (скорость компиляции!), а ей не присущи проблемы планирования ресурсов как в компиляторах под регистровые машины, в итоге код сгенеренный в лоб под стековую машину и разложенный на регистры Z80 (тож в лоб), будет если не быстрее, то уже точно не будет катастрофически отставать от цепочки oberon->ofront->C->sdcc->z80, sdcc тож не подарочек в кодогенерации

Не подарочек, однако его достоинство в том, что он есть! И развивается.

Господа, прошу покорнейше в ветке http://zx.pk.ru/showthread.php?t=18387 раскрыть своё видение каким по-Вашему должен быть компилятор Оберона для ZX.

---------- Post added at 16:22 ---------- Previous post was at 16:11 ----------

не хотелось бы вдаваться в палемику, но всё же

Не хочется впадать в маразм, но всё таки… Вы про модульность когда-нибудь слышали? Хорошо, посмотрим на проблему по-иному. ЗАЧЕМ включать кусок текста программы в кусок текста программы?

Реальный пример из реальной жизни. У меня в проекте Дурак есть тип BOOLEAN, внутри SYSTEM.h, не то что мне так захотелось, так по задумке создателей Офронта назван стандартный тип. Теперь мне понадобилось при портировании под Win32/GCC подключить другой стандартный "модуль" windows.h, в нём тоже есть тип BOOLEAN. При инклюживании они оба накладываются друг на друга, #undef’ить один из них нельзя, так как это не #ifdef’ное определение, а тип. Вот Вам пагубность включения плоского куска текста в плоский кусок текста, без учёта накладок. Какая там к чёрту модульность. Но однако же вбилось в голову как шило, что никак иначе нельзя. Без этого сыр не настолько остр. Sayman, подобны же и Ваши другие претензии. Мы уже давно всё это обсосали на форуме OberonCore, я с Вами теряю время.

в том же пуре бесике или в том же blitz basic`е оператор сравнения не отличается от оператора присвоения. на си его отделили. теперь уже поздно говорить о том, что верно это было решение или нет.

Сравнение и присваивание это всё-таки разные вещи? В классическом Бейсике они помечались одинаковым "=", но отличались LET или IF.

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