Подсчёт ссылок и кириллические имена

За последнее время я доработал освобождение динамической памяти при использовании подсчёта ссылок. Теперь при освобождении записи для неё вызывается функция очистки, которая зануляет входящие в неё указатели, благодаря чему стало возможным автоматическое освобождение цепочек, но, по-прежнему, без разрыва циклических связей. Остаются недоделки, связанные с локальными для подпрограмм записями.

Выбор подсчёта ссылок задаётся ключом -memng counter .

В нынешнем состоянии при сборке самого транслятора с подсчётом ссылок его время работы увеличивается в 1.6 раза.

Также, ощутимым нововведением стало сделанная на днях поддержка кириллических идентификаторов. Кириллица пока ограничивается современными алфавитами русского, украинского и белорусского языков. Имена со смешанным набором латиницы и кириллицы запрещены. Поддержка включается ключом -cyrillic .

Забавно, что внедрив транслитерацию при переводе в программу на Си, из-за допущенной ошибки, из-за которой имена переносились без преобразования, я случайно обнаружил, что в Си также есть поддержка идентификаторов с расширенным набором символов. С этим списком можно ознакомиться в приложении D стандарта языка ISO C99 или ISO C11. Поддержка есть в компиляторах tcc, gcc и clang, но во всех по-разному. В CompCert расширенный диапазон букв недоступен, поэтому транслитерация, всё-таки, пригодилась.

Поддержка работы в WINE

Обеспечена работа транслятора в WINE(в Windows не проверяю). В проект добавлен сценарий build.cmd, который с помощью Tiny CC собирает транслятор из предварительно сгенерированного C-кода, а затем тот собирает сам себя. Как и в GNU/Linux есть возможность сборки и исполнения модулей без промежуточных файлов, когда транслятор все необходимые действия производит сам.

В WINE не всё будет работать хорошо из-за того, что имена файлов регистронезависимые. Над этим ещё нужно поработать.

Накладные расходы проверок

Сделал тест для измерения накладных расходов проверок корректности времени исполнения, которыми транслятор сопровождает основной код. Воплощены проверки: переполнения типа, выхода за границы массива, использования неинициализированных переменных, приведения базовой записи к расширенной, пользовательские ASSERT. Тест представляет собой специальную сборку транслятора, которая несколько раз собирает сама себя. Полагаю, это хороший практический тест. Для сравнения добавлены проверки, доступные в современных компиляторах С: fsanitize=address и fsanitize=undefined.

Для запуска теста используется сценарий benchmark.sh, находящийся в каталоге проекта.

Компилятор: gcc-6.3.0 -O3 -flto.

	Размер, байт	Размер, отношение	Время, секунд	Время, отношение
Без проверок	161 776	1	0.27	1
Восток	219 128	1.35	0.34	1.26
asan undefined	1 284 392	7.93	0.42	1.56
asan address	566 520	3.5	0.74	2.74
asan addr+undef	3 006 456	18.58	0.90	3.33
Восток+addr+undef	3 637 976	22.49	1.04	3.85

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

Скриптовый режим

1. 19 апреля я добавил в транслятор возможность генерации исполняемого файла и возможность его сразу же запустить
2. 25 апреля добавил возможность указать команду модуля - экспортированную процедуру без параметров, что приблизило "Восток" к более удобному понятию программы в оригинальном Обероне в противовес традиционному пониманию программы с единой точкой входа.
3. 5 июля была добавлено скриптовое исполнение, то есть, появилась возможность вызова последовательности экспортированных из разных модулей процедур с параметрами.
4. 24 июля была добавлена опция командной строки -infr (инфраструктура), позволяющая для простых случаев сократить количество параметров, нужных для запуска кода на Оберон. Можно писать так:

   $VOSTOK/result/ost run "Out.Int(1234 * 4567 + 89ABH, 0); Out.Ln" -infr $VOSTOK

   Или, подготовив shell соответствующей функцией

   function ost { $VOSTOK/result/ost run "$1" -infr $VOSTOK; }

   писать так:

   ost "Out.Int(1234 * 4567 + 89ABH, 0); Out.Ln"

Скорость ООП сортировки вставками на Oberon, Objective-C, C++, Go

Продолжаю тестировать транслятор Оберона из проекта "Восток". На сей раз мой взор пал на производительность при использовании объектно ориентированного подхода. Ранее я уже проводил сравнение для Си, Objective-C, C++ на примере сортировки вставками. Недостатком того воплощения было то, что в нём испытывался только вызов виртуального метода, а безопасного приведения от общего типа к расширенному не было. Для Си это требовало написания большего количества текста, чем нужно, поэтому и для остальных языков оно было исключено. Теперь, когда у меня есть транслятор Оберона в Си, эту возможность задействовать куда проще, поэтому я соответствующим образом подправил тест, также заменив Си на Оберон.

Результаты интересные, судите сами.

Скорость пузырьковой сортировки на Oberon, C++, Go, Rust

Воспользовавшись тестом на производительность с форума oberspace, реализованного для разных языков, проверил свой транслятор. Тест представляет собой написанную в лоб пузырьковую сортировку.

Одним из преимуществ использования транслятора Оберона перед непосредственным написанием кода на C/C++ является лёгкая возможность добавления проверок границ массива и использования неинициализированных переменных. Современные компиляторы Си тоже не так просты и позволяют добавлять некоторые проверки (-fsanitize), впрочем, рассматриваемые авторами больше как отладочная возможность. Сравним эти возможности.

Проект Восток. Поехали

Выложил на github исходный код проекта "Восток", который представляет из себя транслятор Оберона. Это нулевая версия, и пока весьма нестабильная. Впрочем, транслятор может не так уж и мало - собрать сам себя, так как в лучших паскалевских традициях написан на собственном входном языке - Oberon-07.

Проект задумывался для возможности партизанского программирования в тылу у противника - коммерчески востребованных языков программирования, используя его как генератор C, C++, Javascript, Java кода и других. Для этого у Oberon есть все предпосылки: язык достаточно прост, чтобы его транслятор можно было создать 1-му человеку, отсутствие навороченных абстракций и низкоуровневых возможностей на уровне ядра языка позволяет относительно легко отображать его на другие языки программирования - как низкоуровневые, так и высокоуровневые, и при этом сам язык достаточно мощен, гибок и защищён от ошибок, чтобы программирование на нём было вполне удобным. Практический смысл этого - возможность использовать один и тот же код на самых разных платформах. Ранее для такой цели я использовал C, но было сложно назвать это удобным и надёжным.

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

Но пока предстоит немало потрудиться над стабильностью транслятора и над качеством производимого C-кода, поэтому о других целях говорить рано.