OberonCore
https://forum.oberoncore.ru/

Доморощенный транслятор и интерпретатор Oberon
https://forum.oberoncore.ru/viewtopic.php?f=28&t=3954
Страница 1 из 4

Автор:  egphilippov [ Понедельник, 30 Апрель, 2012 04:29 ]
Заголовок сообщения:  Доморощенный транслятор и интерпретатор Oberon

Вот, затеял. В ленивом хобби-режиме пишу свой доморощенный компилятор Оберона в целях изучения теории компиляторов и оптимизаций на практике. Парсер AST уже готов, дело за малым - шучу :) Парсер AST опубликовал на Гугл Коде под GPL под тагом "complete".

Для бутстрапа из "пустой" системы почти доделан кроссплатформенный интерпретатор Оберон (делаю на C++). Делается из вышеупомянутого парсера AST, доделываю интерпретатор до рабочего состояния.

На этом интерпретаторе (как только его финализирую, щас он в стадии Incubation) думаю написать уже на Обероне транслятор в машкод i386.

То есть сейчас этап такой что читаются Оберон-модули и преобразуются в AST IR в ОЗУ (этот механизм уже сделан).

Всё это публикую под GPL v3 or later version.

Работы ведутся под Линуксом.

Автор:  Валерий Лаптев [ Понедельник, 30 Апрель, 2012 06:33 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

А вы читали книгу Проект Оберон? Очень рекомендую!
И, конечно, книжку Вирта по компиляторам отдельную.

Автор:  Иван Кузьмицкий [ Понедельник, 30 Апрель, 2012 08:39 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

А для платформы Arduino не было мысли сделать транслятор?

Автор:  egphilippov [ Понедельник, 30 Апрель, 2012 08:54 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Пока не было. Пока линуксом (на атлоне) занимаюсь. Ещё интересна платформа Loongson (MIPS), на ней Ричард Столлмэн сидит. :) Там типа много хардвари более-менее "открытой"...

Автор:  Alexander Shiryaev [ Понедельник, 30 Апрель, 2012 13:25 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

egphilippov писал(а):
То есть сейчас этап такой что читаются Оберон-модули и преобразуются в AST IR в ОЗУ (этот механизм уже сделан).

Раздельная компиляция реализована? :wink:
(см. Compiler Construction, 15.2 (стр. 92))

Автор:  Alexander Shiryaev [ Понедельник, 30 Апрель, 2012 13:29 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Иван Кузьмицкий писал(а):
А для платформы Arduino не было мысли сделать транслятор?

Чем же она так хороша? По-моему, за основу лучше брать ARM. Ну или MIPS.

Автор:  Иван Кузьмицкий [ Понедельник, 30 Апрель, 2012 13:34 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Alexander Shiryaev писал(а):
Иван Кузьмицкий писал(а):
А для платформы Arduino не было мысли сделать транслятор?

Чем же она так хороша? По-моему, за основу лучше брать ARM. Ну или MIPS.


Очевидно, популярностью и простотой в использовании. Да ещё вроде бы Arduino Due выпустили, с ARM-ом

Автор:  Alexander Shiryaev [ Понедельник, 30 Апрель, 2012 13:45 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Иван Кузьмицкий писал(а):
Alexander Shiryaev писал(а):
Иван Кузьмицкий писал(а):
А для платформы Arduino не было мысли сделать транслятор?

Чем же она так хороша? По-моему, за основу лучше брать ARM. Ну или MIPS.


Очевидно, популярностью и простотой в использовании. Да ещё вроде бы Arduino Due выпустили, с ARM-ом


Смысл популярности, грубо говоря, отладочной платы? Чем проще в использовании, чем, например, это?

Автор:  Иван Кузьмицкий [ Понедельник, 30 Апрель, 2012 13:57 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Alexander Shiryaev писал(а):
Смысл популярности, грубо говоря, отладочной платы? Чем проще в использовании, чем, например, это?


http://rubenlaguna.com/wp/2009/03/05/ar ... ndex.html/
http://www.wired.com/gadgetlab/2010/07/ ... s-arduino/
http://www.arduinotutorials.com/

100000 пользователей на 2010 год.

Ардуино у всех на слуху, а вот про указанный Вами SK-MLPC1768 лично я узнал только сейчас.

Автор:  Alexander Shiryaev [ Понедельник, 30 Апрель, 2012 14:04 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Иван Кузьмицкий писал(а):
Ардуино у всех на слуху

Это точно. Только вот не понимаю, почему. Есть же и другие отладочные платы, да и свою сделать не проблема.
Наверное, это как-то связано с тем, что под неё написаны библиотеки на C.

Автор:  egphilippov [ Понедельник, 11 Июнь, 2012 05:34 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

1.

Alexander Shiryaev писал(а):
Раздельная компиляция реализована? :wink:
(см. Compiler Construction, 15.2 (стр. 92))


Раздельной компиляции пока нет, но без раздельной компиляции проект будет считаться ущербным, т.е. обязательна к реализации.

2. Вот кусочек моей переписки на REBOL4 AltME World:

Цитата:
Side note: ...I might want to package my own OBERON interpreter/compiler in all-ends-rounded environment like REBOL/View and REBOL/Command (see http://rebol.com and download REBOL2/View); REBOL is a very nice toy to follow.

My OBERON interpreter (GPL) is partially finished. At least, it reads Abstract Syntax Tree of a set of program modules into internal representation.

I currently work on interpreter. The compiler is not yet started.

But AST reader is generic (GPL), it can be used for any type of program as OBERON source code reader.

And source code syntax is My Own Oberon, i.e. I can modify it to suit any needs.

Автор:  Alexander Shiryaev [ Вторник, 12 Июнь, 2012 03:10 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

egphilippov писал(а):
Раздельной компиляции пока нет, но без раздельной компиляции проект будет считаться ущербным, т.е. обязательна к реализации.

Согласен. И это надо сделать в первую очередь.

Автор:  egphilippov [ Вторник, 12 Июнь, 2012 07:30 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Alexander Shiryaev писал(а):
egphilippov писал(а):
Раздельной компиляции пока нет, но без раздельной компиляции проект будет считаться ущербным, т.е. обязательна к реализации.

Согласен. И это надо сделать в первую очередь.


Предварительные планы а) доделать интерпретатор и что-нибудь на нём погонять (пока в планах такое приложение, как шустрый treepad на GTK - слева панель дерева каталогов файлсистемы, справа plaintext editor для .txt файлов) и б) сделать раздельную компиляцию (по заветам Ильича :) ). Потом уже буду думать о нативной трансляции и прочем.

Автор:  egphilippov [ Вторник, 12 Июнь, 2012 07:33 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Далее в планах activepad: аналог treepad, но справа - не plaintext, а editr+viewer для activetext (plaintext + внедрённые апплеты на некоем языке по мотивам оберона).

Например, такой язык (в качестве одной из гипотез) -

<a href=URL>...</a> - гиперссылка на activepad или на браузер, в зависимости от формата URL (path/xxx.txt - ссылка на activepad, иначе ссылка на веб-браузер)

<oberon>CODE</oberon> - апплетик

Можно вьювером сделать окно типа редактора BlackBox (active edit), + отдельно редактор сырца .txt (raw edit). Кнопарь-toggle "< Raw edit >" "< Active edit >". В языке REBOL диалект VID такой гуиконтрол называется "rotate".

Автор:  egphilippov [ Суббота, 16 Июнь, 2012 06:50 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

В ультра-дальних планах сделать метапрограммный транслятор с-с++ в оберон, чтобы оттранслировать все полмиллиона файлов (Линукса + GNU suite) в кастом версию Оберона. (Надо взять source-based дистриб, возможно это будет Gentoo). Это будет уже другой проект, кодовое название "метапрограммирование Линукса и GNU suite в кастом Оберон". Эта кастом версия Оберона должна быть достаточно развитым диалектом Оберона, чтобы иметь возможность оттранслировать все нюансы сырцов Линукса в оберон-код --- БЕЗ ПОТЕРИ СЕМАНТИЧЕСКОГО СМЫСЛА КОДА. Это значит, что там должен быть и спец-вариант ассемблеров таргет-архитектур Линукса, для семантической гомоморфности си + си++ + асм всех этих архитектур ---> оберон-код на кастом диалекте. Много думаю над этим, но до кодирования ещё далеко. Возможно, понадобится разобраться в таком гиперсложнючем монстре как GCC, и добавить в его метапрограммный форк (metaprogrammaticForkOurGCC(GCC SCM system) бэкэнд генерации кода на этом кастом обероне. Вот такой исследовательский проЭкт.

Автор:  egphilippov [ Суббота, 16 Июнь, 2012 08:47 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Может, кому-то здесь такое интересно :)

Автор:  egphilippov [ Суббота, 16 Июнь, 2012 09:01 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Начать думаю вот с чего. Написать на С++ начальную версию читалки С и С++ кода и писалки этого кода в виде кастом Оберона. Предположим, что такой проект (кодовое название CppToOberon) уже написан, и обозначим его кодовую базу за CppCodebase_CppToOberon.

Затем можно будет скомпилировать CppCodebase_CppToOberon и получить рантайм-машинный-код, обозначим его за Runtime_Binary_CppCodebase_CppToOberon.

Затем можно прогнать CppCodebase_CppToOberon как параметр для Runtime_Binary_CppCodebase_CppToOberon и получить оберон-код для той же задачи, обозначим этот оберон-код как OberonCodebase_CppToOberon.

OberonCodebase_CppToOberon можно прогнать через мой "доморощенный" оберон-транслятор и получить Runtime_Binary_OberonCodebase_CppToOberon и дальше использовать уже его, либо же использовать Runtime_Binary_CppCodebase_CppToOberon --- особой разницы быть не должно. К тому же я намереваюсь сделать InPlaceLauncher для OberonCodebases --- т.е. вызов лаунчера для оберон-сырцов будет приводить к instant-трансляции в машкод, который сразу же (instant, inplace) будет запускаться --- интерпретация через компиляцию --- т.е. как бы мы запускаем OberonCodebase как запускаемые файлы, т.е. хочу сделать сырцы на обероне запускаемыми файлами наподобие шелл-скриптов и других скриптов, --- хочу всё заточить под такой сценарий использования.

Иными словами, OberonCodebase_CppToOberon можно будет запускать inplace, т.е. как скрипт.

Ну и потом наращивать OberonCodebase_CppToOberon, чтобы дорастить его в идеале до OberonCodebase_{LinuxAndGNUSuite}ToOberon, по сценарию, данному двумя постингами выше, ключевое слово "проЭкт".

Такие вот замыслы.

А вот CppCodebase_CppToOberon я планирую сделать, взяв GCC за основу. Не метапрограммно, а вручную поменяв код какой-нибудь из стабильных ревизий GCC.

Автор:  egphilippov [ Суббота, 16 Июнь, 2012 09:21 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Пока что за основу для CppCodebase_CppToOberon от балды схватил svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch - пока что он, понятное дело, продуцирует 0 миллиграмм Оберона :)

Автор:  egphilippov [ Суббота, 16 Июнь, 2012 09:39 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

могутный суперамбициозный проект, но зато интересно.

Автор:  egphilippov [ Суббота, 16 Июнь, 2012 10:46 ]
Заголовок сообщения:  Re: Доморощенный транслятор и интерпретатор Oberon

Лог с двух IRC каналов — обсуждение данного "проЭкта":

* Сейчас общаетесь на #lisp
<egp_> x., а метапрограммирование языка в язык (например, C/C++ в Оберон) тебе интересно?
<egp_> я щас решил этим вплотную заняться
<egp_> Оберон будет расширенный, для метапрограммирования кода БЕЗ ПОТЕРИ СЕМАНТИЧЕСКОГО СМЫСЛА КОДА
<egp_> из С++ и С в кастомный расширенный Оберон
<egp_> более подробно - в конце треда описано тут: viewtopic.php?f=28&t=3954&p=73128#p73128
<egp_> могутный суперамбициозный проект, но зато интересно.
<x.> а какие оно имеет перспективы на сегодняшний день? писать сложный проект стоит хотябы ради чего-то. чтобы пользоваться самому или чтобы хоть кто-то этим пользовался
<x.> а проект, по-моему недостаточно сложный, чтобы стала интересна сама сложность, тут 95% рутина
<egp_> x., ну тут такой вот интерес (кстати оч хороший вопрос).
<egp_> мне вот на данный момент оч интересны референциально целостные языки
<egp_> C и С++ такими языками не являются.
<egp_> у них обязательно требуется такой клей как мейкфайлы - для склеивания референций в коде на си-си++
<egp_> а вот хочется язык, где референции объявляются более явно и более прозрачно
<egp_> оберон и ява - это некоторые шаги в этом направлении.
<x.> только что хотел джаву предложить
<x.> оберон это же говно мамонта, пардон
<egp_> а вот например ребол объявляет все референции в явном виде - это либо локальные файлы либо урлы
<egp_> нене. в целом оберон как явление меня не интересует, меня интересуют его позитивные аспекты некоторые
<egp_> есть такая хорошая пословица как "Literal-mindedness is good."
<egp_> Она говорит как раз о том что КЛЕЙ надо представлять литерально-явно, и без умолчаний типа "НУУУУ КАААААК НИБУУУЦЦЦЬ СЛИНКУУУУЕМ". То есть это исследования идей в области референциальной явности
<egp_> в яве есть такое явление как classpath hell, это большой минус
<egp_> импорт библиотек должен быть более явным, в похожем направлении работает ява-проект Maven
<egp_> (я с Maven правда пока не разбирался)
<egp_> мейкфайлы делают почти невозможным метапрограммирование
<x.> почему это?
<egp_> тогда как Оберон в силу почти максимальной простоты синтаксиса (самый простой синтаксис, безусловно, у лиспов) гораздо удобнее для метапрограммирования нежели си, си++, ява.
<egp_> ну например как распарсить семантику мейкфайла ты представляешь себе? мне кажется это сложновато...
<egp_> вот простота синтаксиса и есть один из больших плюсов оберона.
<egp_> x., просто я очень уверен в том, что использовать make для сборки - это стрельба инструментом типа ПУШКА по задаче типа ВОРОБЕЙ...
<egp_> make сильно круто для такой простой задачи, как простейшая штука - референция.
<x.> если задача простая, можно самому вызывать компилятор, кто мешает
<egp_> мешают традиции: общепринято юзать make
<egp_> просто как сверхзадача — хочется упростить менеджмент процесса производства такой бесплатной ОС как линух плюс гну сьют
<egp_> а такие залипухи как Makefiles этому сильно-пресильно мешают.
<egp_> вот хочется другой язык для референциальной целостности, НЕ язык make
<egp_> в языке make явно и-или неявно используется масса языков из комплекта гну сьют.
<egp_> и это страшная и ИЗЛИШНЯЯ залипуха.
<egp_> сам GCC — уже огромнейшая и ИЗЛИШНЯЯ залипуха — всё можно и нужно сделать намного проще и чтобы шустрее работало. И это полностью возможно, я уверен. Только работы в этом направлении дофигища.
<egp_> вот плюс оберона в том, что у него НАМНОГО шустрее парсинг нежели у явы и тем более у си-подобных языков. И скорость парсинга оберона — не предел совершенства. Предел совершенства скорости парсинга — у визуальных языков, которые хранят код в бинарных файлах
<egp_> и редактирование кода происходит в спец инструменте.
<egp_> ну, тут речь о парсинге кода на данном языке.
<egp_> и вот возможно я не в оберон буду метапрограммировать, а в такой вот бинарный визуальный язык. Тут небольшое сходство с обероновой идеей Juice/Slim Binaries.
<egp_> просто софт должен быть проще и шустрее, и таким вот макаром эти два показателя можно значительно повысить.
<egp_> Для достижения этого дела придётся переписывать тыщи мейкфайлов.
<egp_> То есть Разгребать все эти авгиевы конюшни.
<egp_> y. с канала #forth пишет в ответ на это: "да-да, это правильно". egp_ пишет в ответ: вотвот. гут, что есть согласие.
<egp_> <y.> а я вообще целом, считаю что большинство мэйнстримовых ЯП движутся в тупик
<egp_> <egp_> да они ждут просто здравых идей
<egp_> <y.> да, не спорю - делают много хороших программ и ОС
<egp_> <y.> но вот и больше ничего
<egp_> <egp_> а пока здравых идей нет, всё идёт на самотёке, то есть как попало
<egp_> <egp_> ну вот эта метапрограммная идея про "всё упростить и ускорить" и "убрать мейкфайлы" --- хрен сделаешь. Как-то надо вывернуться подобно тому как Линус штангу поднял...
<egp_> <y.> за полвека развития — развитие в основном экстенсивное
<egp_> в принципе возможно у меня найдутся соратники в списках рассылки вроде os.dev
<egp_> <egp_> в принципе явовский Maven + явовский ant — это шаг к лучшему по сравнению с make... но тоже далеко не всё хорошо, сильно выразительные языки — излишняя выразительность тут не нужна совсем.
<egp_> <egp_> вот... в принципе можно попробовать как-то подобную платформу инициировать... как это лучше осуществить — не очень понятно.
<egp_> <y.> ну, в данной ситуации мне видится разве что качественный переход на какую-то новую платформу разработки ПО
<egp_> <y.> принципиально новую
<egp_> <egp_> короче эту новую платформу я обозначу кодовым словом Phial, реинкарнация первая... просто от балды словечко
<egp_> <egp_> и начну с того что —
<egp_> <y.> хех, фиалка )
<egp_> <egp_> возьму ревизию GCC которая поставляется с убунтой (то есть считается достаточно стабильной) и аккуратно переделаю эту ревизию в кодогенератор кода в некоем более-менее оптимальном бинарном визуальном языке.
<egp_> <egp_> Потом сооружу визуальный редактор для этого языка.
<egp_> <egp_> Ну тут ещё ассоциация с roguelike артефактом Phial of Galadriel :) типа вечный светильник :)
<egp_> <y.> а, вон оно как

Страница 1 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/