Усеченный Паскаль для ZX я лабаю потихоньку.Сообщение от Oleg N. Cher
Усеченный Паскаль для ZX я лабаю потихоньку.
Andrew771, спасибо, мы в курсе.
Правда, Паскаль - не Оберон в двух смыслах. В первом - Оберон более современен и содержит такие средства, которые есть в более поздних языках - Java, C#, и содержит их с самого начала. А в Дельфи они - частью были добавлены по мере его разрастания, да и то не все. Хотя Оберон - язык-ядро, и некоторых средств Паскаля/Дельфи в нём нет (или есть, но не во всех диалектах; впрочем, про диалекты - разговор отдельный).
И когда я искал язык для того чтобы с энтузиазмом им заняться (критерии были: простота, переносимость/портабельность, ясность, прозрачная компиляция в машинный код; потом добавились безопасность и надёжность - чтобы не рисковать жизнью при ежедневном пути на работу) - мой выбор (при любви к Паскаль-синтаксису) оказался не таким уж большим: Модула-2, Оберон или Си. Выбрал я, можно сказать, всё вместе, слегка проигнорировав Модулу-2, ну да ничего. Оберон я рассматриваю как усовершенствованный Паскаль, концептуально более ясный. А транслировать его в Си в общем-то не совсем правильно из-за того, что Си не отражает в полной мере важных возможностей Оберона. Но это было сделано вследствие того, что я себя и свой темп работы знаю - я могу делать проект 10 лет и так его и не закончить. Так что это правда - показывать jerri мне было почти что нечего.
Почему я не влился в твой проект, Andrew771 - да просто потому что у нас разные цели. Мне претит такая большая ограниченность твоего компилятора (ты даже графические процедуры зашил в компилятор, сделав, таким образом, язык-инвалид только для Спека, а даже не для MSX). Плюс закрытые исходники и нежелание делить идеологическое направление развития компилятора с кем-либо ещё. Ну а самая главная причина - это моё нежелание делать компилятор в машкод (я тоже как эти товарищи из предприятия люблю готовые средства для решения своих задач, просто они у меня слегка другие - ну как я могу интересоваться кортексами если я их никогда не видел?). Зато стратегия трансляции в Си окупится при использовании всяческих Raspberry Pi и не-x86 Linux'ов. Потому что заниматься генерацией кода под всё это - сотни человеко-лет работы. А делать, понимаете, хочется всё-таки не игрушку, а рабочий инструмент.
Во-вторых Паскаль - не Оберон в том смысле, что это как бы молитва другому богу, который хотя и сильно похож на первого, но всё-таки имеет другое имя. И люди не смотрят похожи ли эти боги, раз уже решили для себя, что первый бог мёртв. Или если служат(служили) первому богу. Сначала создаётся отношение к чему-либо (девушки в первые 15 минут знакомства оценивают парня, годится ли он в женихи; потом своё мнение в 99% случаев не меняют). Дальше это отношение наполняется энергией исходя из того, какие чувства (положительные или отрицательные) человек получил от предмета, к которому сложилось отношение. Ну это так, немного психологии для саморазвития.
Ну а Andrew771 не приходит в проект ZXDev по его собственным причинам. Хотя это почти тот же самый бог, ну просто очень сильно похож.
Последний раз редактировалось Oleg N. Cher; 29.10.2014 в 14:50.
Andrew771, здорово, что не обижаешься на мои выпады.Просто каждый уменьшает сложность своих задач выбором путей их решения, и в этом смысле я тебя отлично понимаю.
Bolt, ну на самом деле Олег не хочет заниматься генерацией машинного кода сам. Если таких Олегов-единомышленников будет человек десять, то почему бы и нет. XDev ведь по задумке это что? Мультитаргетная и мультиязычная среда разработки. И трансляция в Си - это не диагноз, а только одна из схем трансляции. Тот же Ofront можно рассматривать как бэк-энд (с Си в качестве таргет-платформы) для OP2, на базе которого он построен. Есть также и другие бэк-энды к OP2 (в машинный код для самых различных процессоров) и к расширенному OP2.
Кроме OP2 есть компиляторы Oberon-0 (подмножество Оберона для раскрутки компиляторов) и Oberon-07 в машинный код. Их можно взять в качестве базы для собственного компилятора.
Так что Олег просто отложил задачу генерации машинного кода в долгий ящик, сосредоточившись на кодовой базе, без которой всё равно не обойтись. Могу также добавить, что мультитаргетный компилятор Паскаля мне интересен, но призываю всё же не морочиться с сегментами и оверлеями. Выбором адекватной по размеру адресного пространства платформы для разворачивания компилятора избегается множество проблем. Вместе с тем, не исключаю появление задачи, для которой действительно необходимо втиснуть компилятор в адресное пространство 64 кб, но это жесть. Успехов!
Vitamin, полюбопытствуй: просто статья про ООП, может тебе будет интересно. Автор владеет терминологией и методами ООП в современной реинкарнации. Я же программерствовал десятилетие назад и уже несколько устарел.
Кризис объектно-ориентированного программирования
Alex Rider, вероятно, в январе 2015 будет выпущена первая версия XDevLite - как раз та самая IDE, зашитая в одну exe'шку, о которой ты говорил. Экспериментировать с ней можно уже сейчас. Скачиваешь с репозитория архив XDev (возьми посвежее), открываешь XDev/Bin/Lite.odc и последовательно сверху вниз жмёшь два коммандера (чёрненьких кругляша). В корне сгенерируется файл XDev.exe - это и есть "IDE в одной exe'шке", как ты и просил. В папку с ней также добавь подсистему ZXDev и тестируй. Для пересборки библиотек ещё понадобится утилита Bin/smartlib.exe.
Реалии таковы, что ZXDev сегодня - уже не только среда разработки на Обероне для ZX, но и центр по высокоуровневой разработке для ретро-платформ вообще. Для SDCC вы видели подбор библиотек? Самый большой - как раз в ZXDev. А низкоуровневая разработка меня в первую очередь интересует не как самоцель, но только как фундамент для высокоуровневой.
Господа, анонсирую подсистему MsxDev. Прошу прощения, если для вас это не новость. Также прошу помощи с кодом и демонстрашками, как обычно.
Да я с ними особо и не морочусь, это так, была некая идея, которая отложена в ну уж совсем долгий ящик, а запуск на ZX это было где-то рядом с той идеей. А вообще то, что есть, собирается FPC и тестируется под Ubuntu.
Кодогенераторов было 4 "поколения", последняя версия выдавала хоть и очень неоптимальный код, зато для PIC16, PIC18, PIC24, STM8 и x86. Но всё равно это не то что хотелось бы, компилятор получился довольно запутанный, надо его делить на модули с чётким разделением задач.
Внимательное сопоставление вот чего говорит. Как видим, ZXDev не хотят пользоваться из-за "промежуточной трансляции в Си". Но, кстати, я делаю всё чтобы кодер мог работать на ZXDev без знания языка Си.
А ещё - потому, что опытный асмер фукает, что процедура занимает 10 байт, а могла бы 8. В Оберон-сообществе я вижу другую проблему. Есть система разработки BlackBox Component Builder, и она основана на прямой трансляции в машинный код. Знаете какие недостатки вызывают возмущение? Слабое качество кода (компилятор простой), нет поддержки MMX и других более поздних систем машинных команд, нет генерации 64-битного кода. И это действительно серьёзные проблемы, потому что требуют мощной квалификации и мощного сообщества для их преодоления. О коварные люди! Вам не нравится любой недостаток, даже если в несколько другом ракурсе он является достоинством.
Но из-за "нативного" подхода система BlackBox работает только на x86-Linux. И даже не 64-битный. Но вот когда я смогу собирать его модули своим XDev, тогда это будет серьёзный прорыв.
Bolt, тут есть ещё одна вещь, с которой обязательно сталкивается написатель компилятора. Нужен промежуточный формат объектных файлов, формат для хранения библиотек и т.п. Если взять готовый - могут возникнуть проблемы из-за неподдержки им фич, которые могут понадобиться в компиляторе. Если наваять форматы самому - возникают проблемы из-за несовместимости с другими готовыми популярными форматами и средствами, их поддерживающими. Но как стыковать мультиязыковую систему разработки если не на базе единых форматов? Есть и промежуточное решение - конвертер из "своего" формата в готовый (и обратно). Но тут тоже появляются недостатки... и т.д.
В плане наведения порядка в компиляторе советую статьи Пола Рида (Paul Reed):
(2000) Building Your Own Tools - An Oberon Industrial Case-Study
(2003) An Oberon Linker for an Imperfect World – More Notes on Building Your Own Tools
Есть в торрент раздаче книг и статей по Оберону (на NNM-Club).
Ещё можно почитать книжку "Построение компиляторов" Никлауса Вирта (есть там же). Мне очень нравится как устроены компиляторы Оберона изнутри. Чёткое деление на промежуточный код, фронт-энд и бэк-энд, есть готовый инструментарий для автоматизированного построения фронт-энда из форм Бэкуса-Наура, сам код очень приятно дорабатывать, вносить фичи и т.д.
Последний раз редактировалось Oleg N. Cher; 11.11.2014 в 03:35.
Да, всё так. И про процедуры в 10 байт, и про "прибитость гвоздями" некоторых программ к x86, и про несовместимость... Один из компиляторов поразил меня невозможностью получения указателя на элемент массива, так и сказал: обнаружена "[" вместо ";". Это я к тому, какие интересные бывают реализации "в лоб". FPC тоже примечателен в плане реализации, его исходники открыл... и закрыл. IF THEN ELSE IF на сотни строк, в которые вложены другие IF THEN ELSE IF. В итоге куда там прикручивать кодогенератор так и понял.
Я не против промежуточной трансляции в Си вообще, но, например, для микроконтроллеров PIC16/PIC18 в таком случае всё упирается в те же уже имеющиеся и не совсем совместимые между собой компиляторы. Ещё и платные. Зачем тогда? Как временное решение для генерации хоть какого-то кода?
Книги я искал когда совсем не понимал с чего начать, а сейчас понимание общих идей уже есть, надо думать над реализацией. Например, как в дереве хранить CASE. Но за названия спасибо, а то везде одно и то же: "Сегодня мы будем писать компилятор. Он будет поддерживать один тип byte, глобальные переменные с именем из одной буквы, числа из одной цифры и 4 арифметических действия. А, ещё процедуры без параметров и локальных переменных. Функции добавите сами."
Статья интересная, чувствуется интерес автора к вопросу. С итоговыми выводами согласен, а вот с нет промежуточными заявлениями- нет. В частности, предложенная реализация полиморфизма (через if/switch) де-факто таковой не является.
Например?
Тоже почитал. Автор - типичный теоретик, интересно было почитать его дискуссию с практиком в комментах.
Олег, за весь мир не скажу, но конкретно по этому сообществу - в основном тут люди, ностальгирующие детскими увлечениями. Вот было многое на ZX помимо ассемблера и бэйсика - и C, и паскаль, и форт, и лого, и всякие высокоурвневые редакторы... Но вот Оберона не было ну совсем. Не аутентично оно как-то. Это основная причина непопулярности Оберона здесь. Кстати, как и прочих JScript'ов, кросс-паскалей и даже новомодных фишек АТМ'а (его SDK, например). Остальное вторично.
И с чего сделан такой вывод?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием