Oberon-07M

[valexey]

Появился новый компилятор для языка программирования Oberon-07M. "M" означает, что язык разширен, в частности разрешены одномерные динамические массивы. 

Разработчиком данного компилятора являюсь я сам. Компилятор изначально разрабатывался на Component Pascal, после чего исходные тексты были немного изменены и скомпилированы, самим компилятором Oberon-07M.

Компилятор можно скачать с сайта http://ExaProg.com. Сайт пока очень простой. В дальнейшем планирую сделать его более красивым, выложить туда документацию по компилятору.

Если будут вопросы или найдете ошибки, то пишите мне на почту, адрес почты указан на сайте: http://ExaProg.com.

[valexey]

Попробовал. Под Win7 все собралось (хотя компилирует конечно несколько задумчиво для таких объемов). То есть Hello World даже работает. Попробовал сборщик мусора, сборщик мусора явно лучше чем во всех виденых мною реализациях Оберонов (ну, если не брать в рассчет тот, что в gpcp и прочих живущих в чужих виртуальных машинах).

Однако имеются вопросы:
1) Как у этого сборщика мусора с многопоточностью? То есть если я засандолю несколько потоков, не попортит ли мне сборщик мусора что-нибудь?
2) Что с поддержкой 64 бит?
3) Документация по компилятору какая-нибудь будет?

Ну и предложение — таки именовать исходники не как .txt, а как .ob7 например. Чтобы визуально различались.

[valexey]

...возможность использовать компиляторы вариантов Оберона из-под ББ, чтобы создавались бинарники стандартного ББ-формата.

Не вижу (пока) причин, почему такие бинарники не могли бы бесшовно вписываться в среду ББ.

Согласен. Исходя из общих соображений, по-моему, достаточно переделать только ББй сканер/парсер КП под О7, плюс склепать какую-то переключалку.

Проблем масса. Другой рантайм, например. Другой сборщик мусора. Другая семантика, другие типы. Например Оберон-07 ничего не знает про процедуры связанные с типом записи. Ничего не знает про то, что некоторые записи нельзя расширять, иерархия записей в Обероне-07 не имеет единого корня, в отличае от КП. То есть проблемы будут со интеграцией.

Вот если бы ББ был построен на Обероне, то сверху насадить КП было бы много проще, чем сейчас.

[valexey]

Ах да, еще вопрос — будет ли портабельный вариант компилятора? То есть для невинды, а posix'а (linux/bsd/macos x/qnx/solaris etc).

[DIzer]

...возможность использовать компиляторы вариантов Оберона из-под ББ, чтобы создавались бинарники стандартного ББ-формата.

Не вижу (пока) причин, почему такие бинарники не могли бы бесшовно вписываться в среду ББ.

Согласен. Исходя из общих соображений, по-моему, достаточно переделать только ББй сканер/парсер КП под О7, плюс склепать какую-то переключалку.

Проблем масса. Другой рантайм, например. Другой сборщик мусора. Другая семантика, другие типы. Например Оберон-07 ничего не знает про процедуры связанные с типом записи. Ничего не знает про то, что некоторые записи нельзя расширять, иерархия записей в Обероне-07 не имеет единого корня, в отличае от КП. То есть проблемы будут со интеграцией.

Вот если бы ББ был построен на Обероне, то сверху насадить КП было бы много проще, чем сейчас.

Есть ощушение, что Rifat пошел по пути фичивания 07- на практике, это мало что добавляет к сфере его использования -ИМХО Не самый лучший вариант, целесообразнее разработать новый язык базового уровня на основе  07 ..

[valexey]

Есть ощушение, что Rifat пошел по пути фичивания 07- на практике, это мало что добавляет к сфере его использования -ИМХО Не самый лучший вариант, целесообразнее разработать новый язык базового уровня на основе  07 ..

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

[Rifat]

Oднако имеются вопросы:
1) Как у этого сборщика мусора с многопоточностью? То есть если я засандолю несколько потоков, не попортит ли мне сборщик мусора что-нибудь?
2) Что с поддержкой 64 бит?
3) Документация по компилятору какая-нибудь будет?

Ну и предложение — таки именовать исходники не как .txt, а как .ob7 например. Чтобы визуально различались.

Компилятор расчитан на однопоточные программы, также как и ББ.
Компилятор генерирует 32 битный код, в планах есть сделать 64-битную версию компилятора.
Документация будет в ближашие дни.
Насчет расширения согласен, что txt не очень удачно, что лучше ob7. В принципе вы сами можете переименовать файлы и изменить в bat файле расширение.

[valexey]

Да, уточню конфигурацию где у меня все заработало: Windows 7 32 bit rus.

[valexey]

Однопоточность это печально… Ну да ладно.
И еще вопрос по разработке компилятора – есть ли у набор компиляторных тестов?

[Rifat]

Есть ощушение, что Rifat пошел по пути фичивания 07- на практике, это мало что добавляет к сфере его использования -ИМХО Не самый лучший вариант, целесообразнее разработать новый язык базового уровня на основе  07 ..

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

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

[Rifat]

Однопоточность это печально… Ну да ладно.
И еще вопрос по разработке компилятора – есть ли у набор компиляторных тестов?

У меня есть свои тесты на которых я тестировал, но выложить их пока не могу, их надо еще причёсывать.

[valexey]

Компилятор генерирует 32 битный код, в планах есть сделать 64-битную версию компилятора.

64 битную версию компилятора, или компилятор генерирующий 64битный код? Впрочем, поскольку он компилирует сам себя, то видимо и то и это.

Однако вопрос возникает – как быть с типами данных? В Обероне-07 размеры всех примитивных типов четко расписаны. То есть видимо придется расширять язык новыми типами вроде LONGINT, ну и чтобы NEW(arr, len) len принимал типа LONGINT. Жаль что в Обероне-07 нельзя создавать псевдонимы для примитивных типов, это помогло бы в данном случае.

[Rifat]

Компилятор генерирует 32 битный код, в планах есть сделать 64-битную версию компилятора.

64 битную версию компилятора, или компилятор генерирующий 64битный код? Впрочем, поскольку он компилирует сам себя, то видимо и то и это.

Однако вопрос возникает – как быть с типами данных? В Обероне-07 размеры всех примитивных типов четко расписаны. То есть видимо придется расширять язык новыми типами вроде LONGINT, ну и чтобы NEW(arr, len) len принимал типа LONGINT. Жаль что в Обероне-07 нельзя создавать псевдонимы для примитивных типов, это помогло бы в данном случае.

Как я себе представляю 64 битную весию, что тип INTEGER и указатели будут занимать 64 бита, и не будет необходимости в другом типе данных. Но об этом еще пока рано думать, надо сначала обкатать эту версию.

[valexey]

То что я добавил динамические массивы. Я размышлял над тем нужны ли они, можно ли обойтись только указателями на запись, но пришел к выводу, что в некоторых случаях несколько блоков фиксированного размера не могут заменить одного большого массива. Например, когда требуется за логарифмическое время находить какое-нибудь значение в большом объеме данных, при помощи бинарного поиска.

На самом деле можно и без них. Например см. http://en.wikipedia.org/wiki/VList
Ясно что нам для реализации VList'a произвольного размера потребуется 32 типа массивов фиксированного размера оберона-07.

[valexey]

Как я себе представляю 64 битную весию, что тип INTEGER и указатели будут занимать 64 бита, и не будет необходимости в другом типе данных. Но об этом еще пока рано думать, надо сначала обкатать эту версию.

Это, вообще говоря, нарушит совместимость с Оберон-07 и будет явно противоречить спеке на оный Оберон-07. Но наверное да, пока рано об этом.