Важная информация

User Tag List

Страница 1 из 4 1234 ПоследняяПоследняя
Показано с 1 по 10 из 36

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

  1. #1
    Master Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    759
    Благодарностей: 207
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

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

    Начитавшись в дружественной ветке 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/sdc...%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, но и здесь можно значительно облегчить себе жизнь, пользуясь возможностями Офронта.

  2. Этот пользователь поблагодарил Oleg N. Cher за это полезное сообщение:
    perestoronin (24.01.2013)

  3. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  4. #2
    Member Аватар для Alex III
    Регистрация
    21.05.2006
    Адрес
    г. Старица
    Сообщений
    135
    Благодарностей: 19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  5. #3
    Guru
    Регистрация
    03.01.2006
    Адрес
    Рязань
    Сообщений
    2,935
    Благодарностей: 1071
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  6. #4
    Guru
    Регистрация
    08.10.2005
    Адрес
    Москва
    Сообщений
    9,938
    Благодарностей: 3437
    Mentioned
    2 Post(s)
    Tagged
    1 Thread(s)

    По умолчанию

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

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

  7. #5
    Guru
    Регистрация
    03.01.2006
    Адрес
    Рязань
    Сообщений
    2,935
    Благодарностей: 1071
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  8. #6
    Master Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    759
    Благодарностей: 207
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

    Проект: 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_FOR...rocedures.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...1&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 эмулятор Спектрума? И если да, то какой лучше?

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

  9. Этот пользователь поблагодарил Oleg N. Cher за это полезное сообщение:
    perestoronin (24.01.2013)

  10. #7
    Banned
    Регистрация
    01.12.2010
    Адрес
    г. Санкт-Петербург
    Сообщений
    1,657
    Благодарностей: 1250
    Записей в дневнике
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    Надо думать, в C++ действительно нету модульности, есть только перегруженный аппарат её эмуляции с помощью пространств имён и препроцессора.
    Просто вместо частного случая (решение одной проблемы) используется более мощная технология, которая решает множество проблем включая эту. Там и строк нет, но есть классы и перегрузка операторов, которые позволяют реализовать строки (и не только).

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

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

    #push
    #define TRUE FALSE
    #pop
    Последний раз редактировалось vinxru; 14.03.2012 в 08:44.

  11. #8
    Veteran Аватар для Eltaron
    Регистрация
    16.01.2005
    Адрес
    Ekaterinburg
    Сообщений
    1,187
    Благодарностей: 641
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  12. Этот пользователь поблагодарил Eltaron за это полезное сообщение:
    Oleg N. Cher (14.03.2012)

  13. #9
    Banned
    Регистрация
    01.12.2010
    Адрес
    г. Санкт-Петербург
    Сообщений
    1,657
    Благодарностей: 1250
    Записей в дневнике
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  14. #10
    Guru
    Регистрация
    03.01.2006
    Адрес
    Рязань
    Сообщений
    2,935
    Благодарностей: 1071
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

Страница 1 из 4 1234 ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Создание форума
    от CityAceE в разделе Форум
    Ответов: 43
    Последнее: 10.07.2016, 21:23
  2. Ответов: 172
    Последнее: 10.12.2012, 17:36

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •