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

[Oleg N. Cher]

Начитавшись в дружественной ветке http://zx.pk.ru/showthread.php?t=18336 пожеланий иметь хороший компилятор Оберона с качественной кодогенерацией в Z80, к коим сердечно присоединяюсь, а также советов “лучше напиши компилятор” хочется, тем не менее, сказать что-нибудь полезное по теме вопроса. Даже выбирал имя субдомена http://zx.oberon2.ru с тайной надеждой, что когда-нибудь такой компилятор Оберона для Z80 появится. Это делалось отчасти и для популяризации этой идеи среди спектрумистов. Как и для популяризации Оберонов вцелом. Ибо они того заслуживают.

Всё выше- и нижесказанное есть абсолютное ИМХО и по задумке не должно вызывать гневных выкриков и желания меня задушить. Здесь я не буду касаться узкоспецифичных для ZX вопросов типа кодогенерации не только для плоской модели памяти, ограниченной объёмом 48 кб (с учётом ПЗУ), но и страничной, с переключением банков. Это само по себе нетривиальная задача, но она уже вторичная, первично же следующее.

1. Желание делать всё с нуля своими руками при реализации проектов такого масштаба и сложности как компилятор, включающий высококачественный генератор машинного кода, можно объяснить девелоперским эгоцентризмом, не приводящим обычно к желаемым результатам, либо же попросту трёпу, коий мы рассматривать также не будем. Отчётливо помню этап когда искренне считал, что смогу всё закодить более качественно, чем имеющиеся решения из других рук. Это типичная ошибка незрелых умов. Умение достигать результатов в разумные сроки – это талант приподняться над своим эгоизмом и воспользоваться чужими наработками. Талант поднять паруса и воспользоваться ветром, а не гребля одним веслом против течения. Вроде очевидно, а для многих спектрумистов (я долго читал этот форум и фидоэху ZX.SPECTRUM) вроде и нет. Проблема имеет и противоположную ярко выраженную крайность в виде стремления делать всё на готовых компонентах, но это не про Спектрум.

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

2. Взять готовый фронт и сосредоточить усилия на бэке. Разработку собственного фронта для Оберонов считаю нецелесообразной. В мире Оберон-технологий уже есть много готовых решений, облегчающих и автоматизирующих построение фронт-эндов. Это и COCO/R, и Babel [гуглите]. Практически любой компилятор Оберона довольно чётко разделён на фронт и бэк, и фронт вполне можно взять готовый, если не имеет места блажь из пункта 1.

Разработку бэка для Z80 к готовому фронту я бы посоветовал начать с изучения проектов OPCL https://sourceforge.net/projects/opcl (Oberon, Oberon-2, Active Oberon) и BlackBox Component Builder http://www.oberon.ch/blackbox.html (Component Pascal). В принципе, оцениваю создание плохонького малокачественного генератора кода для Z80 (если не касаться поддержки страничной организации памяти, специфичной для ZX) довольно возможным даже одной особой за разумное время. Наличие огромного количества особ с блажью из пункта 1 подразумевает, что развивать плохонький кодогенератор, сделанный особой из пункта 2, никто не захочет, ибо адепты получению и распространению практических результатов, полезных для нас с вами, предпочитают следование своему пути, коий суть тёмен и неисповедим.

3. Если не имеет место блажь из пунктов 1 и 2, то есть смысл взять самый лучший из доступных имеющихся генераторов Z80-кода – SDCC – и пристроить к нему фронт-энд с какого-либо диалекта Оберона. При этом фронт можно взять готовый и допилить до бэка SDCC.

Данный вариант – совсем не для средних умов, ибо он подразумевает разбор и понимание чужих идей и кода, интеграцию в сформированную команду и принятие сложившихся там принципов разработки. Прибавим желание заниматься явно устаревшим процессором Z80, и большой опыт, и широкий кругозор, и ещё хорошее понимание Оберон-технологий. Наличие способностей, терпения, умения заниматься черновой малоинтересной работой, взаимодействовать с другими людьми, решать возникающие социальные проблемы. А чтобы проект стал общественным достоянием, ещё и заинтересованности в продвижении. И всё это на одной лишь внутренней мотивации. Обладание такими качествами будет свидетельствовать о высоком профессионализме и ориентации на готовый результат. Что-то уже совсем фантастика получается. О трудности и неприемлемости для многих такого пути говорит a) отсутствие качественного кодогенератора Z80, разработанного хотя бы и для Си русскоязычными спектрумистами; b) неприсутствие многих из тутошних умников-кодеров хотя бы в роли баг-репортеров в команде, занимающейся в настоящее время развитием Z80-кодогенератора SDCC. Будем реалистами. Видимо, это проект не того масштаба и сложности, чтобы делать его на мотивации старой ностальгии месяц на коленке, в перерывах между работой и женой.

Вопрос же появления хорошего компилятора не Си, а Оберона для Z80 – это отчасти вопрос популярности Оберона вообще. А вы слышали сколько помоев вылито на Оберон в инете? А ведь их в 99% случаев искренне льют люди, которые не написали на нём ни строчки. Тут вдруг появляется оберонщик и начинает что-то говорить, подкреплять ссылками. Куда там. Давят массой. Принцип ”а нас всё равно больше” никто не отменял. Но это разговор а ля “я Битлз не люблю, правда, я их не слышал, но мне вчера их песню Рабинович по телефону напел”.

А если говорить о человеке с уникальными способностями, то поелику я не вижу себя в этой роли, а попробовать разрабатывать программы на Обероне для Спека хотелось сейчас, посему я пошёл по пути наименьшего сопротивления. Взял самый удачный из известных мне фронтов Оберона – Ofront. А также самый качественный по кодогенерации в Z80 из бэков – SDCC (я не буду называть его архиидеальным, но назовите готовый кодогенератор получше).

http://sourceforge.net/apps/trac/sdcc/wiki/Philipp%27s%20TODO%20list
http://www.z88dk.org/forum/viewtopic.php?id=4178

Соединил их и посмотрел что получится. Получается хорошо. Неидеально, но идеала можно ждать десятки лет, и так и не дождаться.

Извините за излишне выраженный пессимизм. Чудеса случаются. Например, Philipp Klaus Krause. Серьёзный, трудолюбивый и обстоятельный немец из Франкфурта, к тому же отзывчивый, отвечал на все мои письма и баг-репорты. По сей день активный мэйнтенер SDCC-кодогенератора для Z80. Не спектрумист. Почитатель платформы ColecoVision http://www.colecovision.eu/ColecoVision/.

Ещё аргумент в пользу пункта 3: кодогенератор SDCC для Z80 совершенствуется и по сей день. И ещё один плюс: в довесок, кроме Z80, там есть ещё бэки и для других микропроцессоров.

Теперь о неизбежных минусах. Должен заметить, что мне не попадалась ни одна безглючная версия SDCC. Это к вопросу о сложности реализации C++ или сложности разработки качественного кодогенератора. Это вовсе не простое дело, я вас уверяю. Оно может казаться простым лишь на первый неприкаянный взгляд.

Так как же я решил проблему? А я пользуюсь такой версией SDCC, баги которой мне известны. Поэтому научился их обходить. Это вопрос тонкий, а значит опять перечитываем статью Алекса Черемхина и горько усмехаемся. Или тихо плачем. Правда, может там у них что-то и поменялось с бажностью, не знаю. Давно не качал новых билдов.

Нестыковка между обстоятельным герром Краузе и баговитым кодогенератором? Я бы объяснил это устаревшим принципом разработки [пробую, вроде работает, идём дальше]. В Оберон-кругах такой стиль не принят и более того – осуждаем. И в этом ещё один барьер в овладении Оберон-технологиями (заметьте, сюда включаем не только язык). Хотя и сам Оберон – язык, который помогает программисту обнаруживать узкие места в коде по возможности раньше. Это мало касается изобретённой мною технологии разработки через Ofront/SDCC, но и здесь можно значительно облегчить себе жизнь, пользуясь возможностями Офронта.

[Alex III]

Вообще, имеет смысл сия затея. Осталось только заинтересовать сообщество...

[alone]

Статья начинается с того, что в C++ нет модульности. Дальше не читал.

[Titus]

Ничего особого в статье не нашел. Личный опыт автора борьбы с глюками компиляторов, неудобство Си++ для определенных 'универсальных' задач данного автора и т.д. В основном вода. Вот я туда пошел, мне неудобно оказалось, вот другие тоже в отладчиках сидят.

Дебаггер нужен не только для того, чтобы отловить глюки. А еще, между прочим, для того, чтобы по шагам посмотреть работу какого-либо алгоритма. Это раз.
Два - лично для меня, некорректно сравнивать Оберон с Си++ и Джавами. Я сравню с обычным Си. Мне Си удобней всего. Мне нужны беззнаковые данные. Мне нужно самому контролировать память. Мне не нужно никакой самодеятельности со стороны компилятора и, тем более, неведомого мне межстрочного кода контроля за правильностью работы моей программы. Хочу вызывать функцию по указателю. Хочу обращаться к массиву данных хоть словно, хоть байтово, независимо от того, как я его определил. Я пишу ЭМУЛЯТОРЫ, и из всех ЯВУ простой Си для меня удобней всего. Так что все дело задач, манеры написания и даже склада характера программиста. Имхо.

[alone]

Я, кстати, не понял, в чём у автора была проблема с int **.

[Oleg N. Cher]

Пока в качестве компилятора предлагаю использовать:

Проект: https://github.com/Oleg-N-Cher/BB-XDev
Скачать: https://github.com/Oleg-N-Cher/BB-XDev/zipball/master
Документация: /ZXDev/Docu

Предполагаемые направления дальнейшей деятельности:

1. Адаптация к технологии ZXDev библиотек MegaBasic, Supercode, Supercode 2 и New Supercode.
2. Адаптация к ZXDev библиотеки Sprite Pack из Z88DK ( http://www.timexsinclair.org/alvin/#SP , http://www.mojontwins.com/warehouse/splib2-tutorial.pdf ).
3. Адаптация к ZXDev наработок SerzhSoft’а, в частности, “40 лучших процедур” ( http://vladik1232008.narod.ru/ZX_FORUM_40_Best_procedures.html , http://vladik1232008.narod.ru/ZX_Review11_12.html )
4. Портирование с Hisoft Pascal библиотеки для черепашьей графики Turtle.
5. Адаптация к ZXDev процедуры NiceType (красивый вывод текста) с моей игры Sea Fight ( http://colossoft.anarxi.st/?go=seafight ).
6. Порт игры “Бега Мышей” (из книги “Как написать игру для ZX Spectrum”) с Laser Basic на Оберон-2 (в качестве демонстрации технологии ZXDev).
7. Порт игры Laser Cube с Laser Basic на Оберон-2 с целью её ускорения.
8. Порт игры Dark Woods для ZX Spectrum ( http://zx.pk.ru/showthread.php?t=18457 ).

Следует предпринять и такие шаги:

1. Доработка Офронта для решения этой проблемы: ( http://sourceforge.net/tracker/?func=detail&atid=350599&aid=3452891&group_id=599 ).
2. Доработка Ofront до возможности полноценно использовать линейку беззнаковых типов в программах на Обероне – SHORTCARD (8 бит), CARDINAL (16 бит), LONGCARD (32 бита), что важно для оптимальности алгоритмов при разворачивании кода на процессор Z80. Название типов исходит из языка Модула-2, но обсуждаемо.
3. Разработка быстрой графической библиотеки для ZX Spectrum (оконное GUI, шрифты разных размеров, заливка текстурой, спрайты, тайлы, векторная графика с масштабированием). Создание аналогичной по функционалу и по вызовам библиотеки для других платформ (для облегчения переноса игр со Спектрума и для одномоментной разработки для Спектрума и чего-то ещё).
4. Совершенствование подсистемы ZXDev для упрощения разработки (чтобы новичкам легче было создавать на Обероне программы для ZX Spectrum), наращивание её возможностей новыми библиотеками и насыщение идеями, создание информационного пространства в рамках технологии “ZX+Oberon”.
5. Дальнейшая доработка Офронта до транслятора, включающая поддержку языка Component Pascal, с возможностью использовать язык КП для программирования процессора Z80.

Я не собираюсь реализовывать всё вышеперечисленное сам, всего на свете не сделаешь, поэтому будем посмотреть, какой это вызовет интерес и одобрение у вас.

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

Выскажите своё мнение насчёт того, стоит ли включать в поставку системы BB-XDev эмулятор Спектрума? И если да, то какой лучше?


Статья начинается с того, что в C++ нет модульности. Дальше не читал.
Надо думать, в C++ действительно нету модульности, есть только перегруженный аппарат её эмуляции с помощью пространств имён и препроцессора.

[vinxru]

Надо думать, в C++ действительно нету модульности, есть только перегруженный аппарат её эмуляции с помощью пространств имён и препроцессора.

Просто вместо частного случая (решение одной проблемы) используется более мощная технология, которая решает множество проблем включая эту. Там и строк нет, но есть классы и перегрузка операторов, которые позволяют реализовать строки (и не только).

Я бы на вашем месте сделал мы макросы и include. С помощью них можно реализовать даже шаблоны (template) на языке типа C, гораздо более гибкие (и еще менее поддающиеся отладке :) ), чем на C++.

Только надо добавить области видимости для макросов.

#push
#define TRUE FALSE
#pop

[Eltaron]

3. Если не имеет место блажь из пунктов 1 и 2, то есть смысл взять самый лучший из доступных имеющихся генераторов Z80-кода – SDCC – и пристроить к нему фронт-энд с какого-либо диалекта Оберона. При этом фронт можно взять готовый и допилить до бэка SDCC.
У этого варианта гигантский плюс - возможность линковаться с сишным кодом.
С одной стороны вроде и незачем, ведь сишных либ для ZX как бы и нету. Но с другой си как промежуточный язык очень популярен, и в этом своем качестве уступает только ассемблеру. Взять хотя бы lex/flex и bison/yacc.
Также си сплошь и рядом используется как промежуточный язык в компиляции Haskell'а и Lisp'а. То, что оберон компилируется в z80-код через си - это настолько нормально, что меня даже удивляет, что у этой идеи есть противники.

[vinxru]

и в этом своем качестве уступает только ассемблеру.

LLVM еще очень популярен. И для него есть всякие программы.

[alone]

С одной стороны вроде и незачем, ведь сишных либ для ZX как бы и нету.
Графические есть.

[Oleg N. Cher]

Я бы на вашем месте сделал макросы и include. С помощью них можно реализовать даже шаблоны (template) на языке типа C, гораздо более гибкие (и еще менее поддающиеся отладке :) ), чем на C++.
А ещё шаблоны можно реализовать на Обероне и без макросов: http://sage.com.ua/ru.shtml?e1l5


Графические есть.
Озвучьте, если я что-то упустил.

[alone]

http://www.z88dk.org/wiki/doku.php

[vinxru]

А ещё шаблоны можно реализовать на Обероне и без макросов: http://sage.com.ua/ru.shtml?e1l5


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

[vinxru]

01 TYPE
01.1 TEMPLATE<CLASS XXX>
02 ListStdItem = POINTER TO RECORD
03 value: XXX;
04 END;

Теперь у нас есть все возможные типы ListStdItem<LONGINT>, ListStdItem<DOUBLE>, ListStdItem<STRING>, ListStdItem<ListStdItem<STRING>> и т.п.

05
05.1 TEMPLATE<CLASS XXX>
06 StdList = OBJECT
07 VAR
08 list: List;
09
10 PROCEDURE &New(options: SET);
11 BEGIN
12 NEW(list, Compare, options)
13 END New;
14
15 PROCEDURE Compare(first, second: ANY): LONGINT;
16 VAR
17 nFirst, nSecond: XXX;
18 BEGIN
19 nFirst := first(ListStdItem<XXX>).value;
20 nSecond := second(ListStdItem<XXX>).value;
21 IF nFirst < nSecond THEN
22 RETURN -1
23 ELSIF nFirst > nSecond THEN
24 RETURN 1
25 ELSE
26 RETURN 0
27 END
28 END Compare;
29
30 PROCEDURE Add(x: XXX);
31 VAR
32 item: ListStdItem<XXX>;
33 BEGIN
34 NEW(item);
35 item.value := x;
36 list.Add(item)
37 END Add;
38
39 PROCEDURE Insert(pos: LONGINT; x: XXX);
40 VAR
41 item: ListStdItem<XXX>;
42 BEGIN
43 NEW(item);
44 item.value := x;
45 list.Insert(pos, item)
46 END Insert;
47
48 PROCEDURE Remove(i: LONGINT);
49 BEGIN
50 list.Remove(i)
51 END Remove;
52
53 PROCEDURE IndexOf(x: XXX): LONGINT;
54 VAR
55 item: ListStdItem<XXX>;
56 BEGIN
57 NEW(item);
58 item.value := x;
59 RETURN list.IndexOf(item)
60 END IndexOf;
61
62 PROCEDURE GetCount(): LONGINT;
63 BEGIN
64 RETURN list.GetCount()
65 END GetCount;
66
67 PROCEDURE GetItem(i: LONGINT): XXX;
68 VAR
69 item: ANY;
70 BEGIN
71 item := list.GetItem(i);
72 RETURN item(ListStdItem<XXX>).value
73 END GetItem;
74
75 END LongintList;

Теперь у нас есть все возможные типы StdList<LONGINT>, StdList<DOUBLE>, StdList<STRING>, StdList<StdList<STRING>> и т.п.

[Error404]

http://www.z88dk.org/wiki/doku.php

Вот кстати - да.
SDCC или Z88dk?
Кто чем пользуется, какие + и - ?

[Eltaron]

Вот кстати - да.
SDCC или Z88dk?
Кто чем пользуется, какие + и - ?
Надо портировать под sdcc либы z88dk, и у последнего вообще плюсов не останется :)
Хороших си компайлера только два - sdcc и iar. Удобный только один - sdcc.
Я к нему еще и отладчик прикрутил, через gdb и ZXMAK2. Соберу всё под винду и зарелижу.

[Robus]

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

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

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



PROCEDURE Compare(first, second: ANY): LONGINT;
VAR
nFirst, nSecond: XXX;
BEGIN
nFirst := first(ListStdItem<XXX>).value;
nSecond := second(ListStdItem<XXX>).value;
IF nFirst < nSecond THEN
RETURN -1
ELSIF nFirst > nSecond THEN BEGIN
RETURN 1;
END ELSE BEGIN
RETURN 0;
END;
END Compare;


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

[ZEK]

поймёт ли он просто "END;" ?
Нет, имя обязательно


Красным выделю вариант. Меня интересует поймёт ли компилятор
Нет, скобки begin-end больше нет


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

[Error404]

Я к нему еще и отладчик прикрутил, через gdb и ZXMAK2. Соберу всё под винду и зарелижу.

Отладчик source-level ?

[Eltaron]

Отладчик source-level ?
Ага, точки останова прямо в сишном коде.

[bigral]

То, что оберон компилируется в z80-код через си - это настолько нормально, что меня даже удивляет, что у этой идеи есть противники.

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

[Error404]

Ага, точки останова прямо в сишном коде.

Это очень интересно. Когда планируешь релиз? Будешь выкладывать - создай отдельную тему, иначе можно пропустить столь полезное усовершенствование.

[Eltaron]

Это очень интересно. Когда планируешь релиз?
Когда 1) соберу под винду binutils-z80 и пропатченый sdcc, 2) настрою какой-нибудь eclipse для работы с gdb-z80

---------- Post added at 10:26 ---------- Previous post was at 10:15 ----------


Тогда гипертрофируя твою идею все языки программирования должны компилиться с С? Не глупо ли плодить промежуточные уровни? Компилить надо только в ASM.
Нет.
Я лишь говорю, что нет ничего плохого в компиляции в си - это очень эффективный и достаточно низкоуровневый язык.
Если выбирать между существующим компилятором в Си, и несуществующим компилятором в асм, я бы выбрал первый.

А если есть большое желание написать свой компилятор - давай gcc портируем? Очень разумная архитектура и понятный код (в отличие от кошмара в sdcc), плюс он уже содержит поддержку 8битного процессора 68HC11 (Motorola), чья архитектура довольно близка z80 - есть что взять за основу, плюс есть исходники поддержки z80 в древнем gcc-2.95.
Сразу получим поддержку си, c++, фортрана, objective c и Ады. Потом можно туда и оберон прикрутить.

[Error404]

Когда 1) соберу под винду binutils-z80 и пропатченый sdcc, 2) настрою какой-нибудь eclipse для работы с gdb-z80


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

Кстати о портировании. Есть что-нибудь интереcное в исходниках на Обероне c точки зрения портирования на Z80? Например, стек TCPIP? Библиотека для работы с FAT? Небольшие операционные системы (размером с Contiki)?



Я к нему еще и отладчик прикрутил, через gdb и ZXMAK2. Соберу всё под винду и зарелижу.

А за счет чего связываются gdb и ZXMAK2? Интересуюсь с точки зрения чего надо запилить в моем эмуляторе Ориона, чтобы с твоим фронтендом отладчика можно было заменить ZXMAK2 на мой эмуль. Есть какая-то спецификация на то, что для этого должно быть в эмуле? Очень хочется нормально дебажить С-код для Ориона. Задолбался printf-ами отлаживаться.

[bigral]

давай gcc портируем? Очень разумная архитектура и понятный код

Это утопия, gcc как проект рассчитан на mainstream (читай системы с плоской организацией памяти 32bit или 64bit). Так что прикручивание к нему всяких "извратов" из компилеров для embedded систем это задача противоречащая самой сути проекта gcc (имеются в виду все системы с ограниченным в 64kb прямо-адресуемым пространством). К примеру OpenWatcom поддерживает i8088 и всякие там HUGE, LARGE, TINY поробуй сделать все тоже самое для gcc (если сможешь то будет смысл обсуждать дальше).

SDCC специально создан для таких систем и развивается в этом направлении (Embedded C).

[Eltaron]

К примеру OpenWatcom поддерживает i8088 и всякие там HUGE, LARGE, TINY

Ты прикалываешься? Это не столько ватком поддерживает, сколько процессор. Наш проц и знать не знает о страницах и сегментах, и никакой sdcc этому серьезно помочь не сможет.


SDCC специально создан для таких систем и развивается в этом направлении (Embedded C).
Гм, это звучит как цитата из пресс-релиза.
Но вообще у нас плоская память, больше 40 килобайт доступно для софта.
Страницы - черт с ними, на первых порах не нужны. А вообще это задача линкера по разным страницам код распихивать. У gcc нет своего линкера, он ассемблерный листинг генерирует, и чао.

---------- Post added at 17:30 ---------- Previous post was at 17:29 ----------


Так что прикручивание к нему всяких "извратов" из компилеров для embedded систем это задача противоречащая самой сути проекта gcc
WinAVR, кстати, вообще изврат, правда?
Однако самый популярный си компилер под AVR

[bigral]

Ты прикалываешься? Это не столько ватком поддерживает, сколько процессор. Наш проц и знать не знает о страницах и сегментах, и никакой sdcc этому серьезно помочь не сможет.


Ну как раз первичен тут Watcom потому как например 32bit flat он поддерживает тоже! Но в отличие от gcc портированного под DPMI и Windows он поддерживет coff формат с для real mode приложений. Так вот идеология дальнейшего развития SDCC как-бы намекает на создание подобного формата OBJ-ей рассчитанных на страницы и модели памяти tiny, large, huge и т.д.


Но вообще у нас плоская память, больше 40 килобайт доступно для софта. Страницы - черт с ними, на первых порах не нужны. А вообще это задача линкера по разным страницам код распихивать. У gcc нет своего линкера, он ассемблерный листинг генерирует, и чао.

ГЫ, так давно известно что flat это "large tiny"! Эту модель вообще поддерживает ЛЮБОЙ компилер какой не возьми, токо вот толку нам от этого? Зачем отказываться от нужных фич?


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

[Eltaron]

ГЫ, так давно известно что flat это "large tiny"! Эту модель вообще поддерживает ЛЮБОЙ компилер какой не возьми, токо вот толку нам от этого? Зачем отказываться от нужных фич?
Ты про вот это? http://zx.pk.ru/showpost.php?p=468974&postcount=10
Данные ок, а код? Переход (jp) из одной банки памяти в другую возможен?


х.з. не видел, не использовал, расскажи если знаешь что он может в плане облегчения жизни программистам на платформах со страничной организацией памяти.
Я не в курсе про страницы в avr, но речь же шла об embedded :)

[bigral]

Ты про вот это? http://zx.pk.ru/showpost.php?p=468974&postcount=10
Данные ок, а код? Переход (jp) из одной банки памяти в другую возможен?
Я не в курсе про страницы в avr, но речь же шла об embedded :)

И про то тоже, на счет кода там уже были давно разные модели памяти не уверен работают ли они вообще и на каких процессорах. В embedded кроме страниц бывает куча всего всего всего (та же harvard architecture или LoHi у 1818вм01 или доступ к битовым областям), самый крутой в этом плане компилятор AS. По хорошему SDCC нужно компилить именно под него.

А вообще по этому вопросу интересно спросить тех кто проффесионально пишет софт под 8/16 bit на пользуясь какой нибудь крутой комерческой софтиной (IAR?). Есть тут такие? Кто может сказать что больше всего подходит для Z80 и спекки?

[Madzi]

Есть визуальный разработчик для микроконтроллеров Деконт 128 (внутри Z80). Компилирует визуальная схема -> C -> ASM -> машинный код (не особо оптимальный естественно)

[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, действительно.

[Vitamin]

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

[bigral]

А почему не сразу в машинный код? Асм тоже промежуточная стадия.

Потому что машинный код нечитаем а значит и контроль качества кода провести не легко его невозможно подправить\оптимизировать руками где это нужно будет.

[Oleg N. Cher]

Почему это "контроль качества кода провести не легко"? Дизасм никто не отменял.


"Проблема" решается соблюдением табуляции и отказом от макаронных функций на несколько экранов.
Как показала многолетняя практика, табуляция действительно сильно помогает, но всех ею заставить пользоваться не получится. Поэтому часто лучше действительно вшить такую полезную вещь в язык. Оберон часто вынуждает подставить имя там, где другие языки обходятся неявным "self" или "this", что заставляет программиста осмыслить глубже то, что он собирается сказать. Подчёркивает суть. В ветке http://zx.pk.ru/showthread.php?t=18336 опять же обсуждалась технология использования в Си анонимных "фреймов", я показал как в Обероне/Паскале сделать их поименованными, а программу – более наглядной.

Поэтому END – это анонимное окончание, а END Proc – поименованное, названное или, если хотите, обозначенное. Да, и в Си можно писать

}/*Proc*/
или

}/*if*/
но заставить ВСЕХ так писать всё равно не получится.

[Vitamin]

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

[Oleg N. Cher]

Справедливо, я согласен.