Web-среда 0.1 для транслятора Web-sandbox 0.1 for the translator

Доработана и обозначена как версия 0.1 написанная на Go и JavaScript web-среда(песочница) для взаимодействия с транслятором Восток. Среда позволяет редактировать модули на Обероне, запускать экспортированные процедуры, преобразовывать модули на другие языки программирования. Модули, доступные по умолчанию из окружения транслятора, ограничены в доступе к возможностям сервера.

The web-sandbox written in Go and JavaScript for interacting with the Vostok translator has been fixed as version 0.1. The sandbox allows you to edit modules on Oberon, run exported procedures, convert modules to other programming languages. Modules available from the default translator's environment have restricted access to server's resources.

Перевод на другие языки в песочнице

Песочница пополнилась возможностью вызывать транcляцию в доступные языки, то есть, С, Java, JavaScript. В выводе кода акцент смещён на читаемость, поэтому для неё транслятор вызывается с опциями, минизирующими создание дополнительного кода, необходимого для повышения диагностики ошибок или воплощения необычных режимов исполнения.

Заодно с добавлением команд трансляции на сайт песочницы были добавлены новые примеры кода.

Оптимизация памяти в JavaScript при проверке индексов массивов

Добавив в benchmark, в качестве которого служит сам транслятор, исполнение версий на Java и JavaScript, обнаружил, что для последнего при включённых проверках индексов массивов происходит ~ 8-кратный перерасход памяти по сравнению с выключенными проверками, что было незаметно на небольших программах. Расход памяти, в свою очередь, приводит и к ощутимо большему времени исполнения, чего, опять-таки, не было в простых тестах.

Перерасход был вызван, в основном, тем, что методы доступа к элементам массива находились в самом массиве, что было сделано в расчёте на потенциально высокую возможность оптимизации при JIT-исполнении и без учёта влияния на занимаемую память. Замеры показали всё, как есть - и неоправдавшиеся надежды на оптимизации, и ужасы накладных расходов на сборку мусора.

Оптимальным по всем параметрам решением оказалось добавление методов доступа непосредственно классу Array вместо создания дополнительных обёрток.

Дополнительно в JavaScript была устранена генерация проверок индекса для простых случаев, когда статически известно о гарантиях корректного обращения к массиву. Также, была усовершенствована пометка переменных, которые участвуют в вызовах подпрограмм в качестве VAR-параметров, что в Java и JavaScript имитируется через массивы. Это позволило устранить превращение в массивы переменных в вызовах NEW, PACK, UNPK.

Проверка арифметического переполнения и инициализированности в JavaScript

Поправил до уровня работоспособности генерацию кода JavaScript для проверки арифметических ошибок и состояния инициализированности переменных. Генерация проверок включается и выключается отдельно для каждого вида, но они не являются полностью независимыми, так как проверка арифметики может быть выполнена заодно с инициализированностью.

Например:

r = a * b;
if (-0x80000000 < r && r < 0x80000000) {
...

Проверяемое условие не будет выполнено как в случае выхода за границы, так и в случае, если переменные будут заданы как NaN в качестве неиницилизированности, что позже может быть дополнительно проверено.

Проверка границ массива в JavaScript

Добавил проверку индекса на выход за границы массива для кода, сгенерированного в JavaScript, что было анонсировано почти 2-а года назад. Применённая модель проверки, естественно, замедляет выполнение, но всё же не приводит к взрывной деградации скорости в современных браузерах и в node.js, как это бывает с исполнителями JavaScript.

Был применён такой подход:

array = new Array(len);
this.at = function(index) {
  if (0 <= index && index < len) {
    return array[index];
  } else {
    throw new RangeError();
  }
};

..

a = arr.at(i);

len находится в контексте объемлющей функции и не меняется после установления, что позволяет jit-компилятору оптимизировать проверки вплоть до сравнения с константами, что может быть очень эффективным. Впрочем, накладные расходы на методы никуда не деваются, а Object.freeze для обеспечения гарантии отсутствия подмены методов и гипотетической возможности их встраивания не помог для оптимизации.

Связка с кодом на других высокоуровневых языках

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

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