Новость года имхо.

Следующая версия JavaScript движка в продуктах Mozilla будет использовать на низком уровне байткод интерпретируемый виртуальной форт-машиной. Код написан компанией Adobe, для ихнего движка ActionScript 3, который планируется внедрять на мобильных телефонах.

https://mail.mozilla.org/pipermail/tama ... 00180.html
http://www.onflex.org/ted/2007/12/meet- ... ted-to.php

Кусок кода (code/vm.fs) :

Начало проекта.

Tamarin Project
Ноябрь 7th, 2006

Adobe и Mozilla договорились меж собой и создали совместный проект Tamarin, суть которого сводится к тому, что Adobe откроет сорсы своей виртуальной машины, использующейся сейчас в Flash Player 9 - Adobe® ActionScript™ Virtual Machine (AVM2), для нового опен-сорсного проекта Mozilla.

Вот это новогодний подарок!!! Ура! Наконец-то!!!
Спасибо за новость!!!

ОПпа..... да ведь это-же виртовский Оберон....
Франц писал один из бакэндов (конкретную версию системы
сейчас не вспомню ) для него.

там загружаемый формат файлов в виде аннотированного
(и оптимизированного) дерева грамматического разбора.
они утверждают, что это гораздо быстрее и эффективнее,
чем аналогичный jit для асмо-подобных байткодов.

Code Generation On-The-Fly: A Key to Portable Software // M.Franz
[http://www.ics.uci.edu/~franz/Site/pubs-pdf/DissETH10497.pdf]

да, и ещё в той среде говорят (тихонько так), что Яву "слизали" (Билл Джой)
как раз с их детища, "перелицевав" только на свой манер в меру разумения...

С одобрения Хищника излагаю ниже свое понимание работы М. Франца и ее реализации в tamarin-tracing.

Франц известен в первую очередь благодаря технологии Juice, о которой уже упомянул garbler. Однако Juice это не разновидность JIT(о которой сказано ниже), поскольку переносимые исполняемые модули Франца компилируются в машинный код полностью, перед запуском.

Технология JIT предназначена для оптимизации быстродействия интерпретаторов(APL, LISP, Smalltalk, SELF, ...), здесь, вместо прекомпиляции во время работы программы динамически определяются «узкие места», которые на ходу и транслируются в машинный код. Благодаря своей адаптивности JIT-компиляторы в общем случае способны найти те «горячие» участки, которые проглядит даже самый мощный статический компилятор.

В работе «Incremental Dynamic Code Generation with Trace Trees» Францем предложена интересная новая разновидность JIT. Единицей динамической компиляции в этой системе является цикл, который в общем случае не связан границами методов, процедур, может охватывать часть библиотечного кода и тд. По мере исполнения инструкций виртуальной машины интерпретатор определяет часто повторяемый код(здесь не обходится без эвристик, счетчиков частоты выполнения и прочего, чем характеризуется обычная JIT) и строит для него специальную структуру данных — дерево трассы, которое впоследствии и компилируется динамически в исполняемый код. Такие деревья со временем расширяются, охватывая альтернативные ветви внутри цикла или при переходе на внешний цикл, и в этих случаях код соответствующих деревьям участков полностью перекомпилируется. Деревья трасс предварительно транслируются в удобный для окончательной генерации машинного кода вариант традиционного SSA(промежуточное представление: линейный код с переменными единственного присваивания).

В случае с tamarin-tracing перед разработчиками стояла задача адаптировать виртуальную машину ActionScript для использования в мобильных и других ограниченных по ресурсам системах. В результате была создана FVM, как «микрокод» для инструкций ВМ AS, с использованием трассирующего JIT-компилятора. В интересах разработчиков было реализовать максимум кода интерпретатора ActionScript на FVM, чтобы воспользоваться динамической компиляцией, по этому они написали простенький компилятор на Python, который из фортовских исходников создает cpp-файлы с последовательностями инструкций FVM. Во время трассировки стековые операторы Форта превращаются в различные манипуляции с локальными переменными(стек деконструируется). Далее в игру вступает еще одно промежуточное представление — LIR, регистровая машина, инструкции которой и переводятся в исполняемый код конкретного процессора.

Нужен ли Форту трассирующий JIT или нам хватит stc-кода с peephole-оптимизацией? В новой системе понижено общее быстродействие интерпретации: потребуется использовать классический шитый код с трассировкой в next, нужно динамически строить деревья и тд. С другой стороны, новый JIT проявил бы себя лучше простейшего форт-компилятора там, где это действительно необходимо: в критичных по времени циклах. Этот вопрос пока остается открытым.

А не цель? - сделать JIT переносимой реализацией.
Который сам себя еще и оптимизнет:) на целевом CPU.



Смотрел исходники и в формате ( abc) байт-кода увидел команды работы
со стеком DUP DROP SWAP . Форт команд работы со стеком данных, например OVER и др в формате abc нет. ( «микрокод» для инструкций ВМ AS не совсем имеет прямое соответствие )

Насколько тогда оправдано использование именно Форт языка в качестве
программирования некоторых частей tamarin-tracing?



Интересно на каких эвристиках определяется какого объема предварительно построить дерево? ( при предварительном прогоне?) и как оно видоизменяется в процессе использования программы?

Вопрос: Если байт-код используется для переносимости исполняемых модулей,
то может имеет смысл предусмотреть в нем разные опкоды команд ( эквивалентных
цепочек по семантике ) и привязать компиляцию кода в разные опкоды, ( несколько разных участков байт-кода для архитектурно отличающихся контроллеров ( CPU) ).
А JIT будет запрашивать о наиболее адекватных для трансляции байт-кодах целевого CPU.

Боюсь, что нет. Интерпретатор для FVM и трассирующий
JIT-компилятор написаны на C++. Ассемблер под конкретную
целевую платформу подключается заголовочным файлом.
JIT работает уровнем выше, на стадии интерпретации FVM и
байт-кода ActionScript. Здесь, если мы имеем на стадии
трассировки FVM-код, состоящий из нескольких AS-примитивов,
то компилятор способен их развернуть в оптимизированный
машинный код. По этому и имеет смысл реализовывать
интерпретатор ActionScript на Форте. Собственно, это разъяснено
в списке рассылки Mozilla по ссылке ygrek'а.


Действительно, в байт-коде ActionScript(abc) со стеком работают
только dup, pop, swap. FVM существует уровнем ниже, и чтобы
понять, как оно выглядит, смотрите в исходниках fs-файлы. Если
же хотите посмотреть на интерпретатор FVM и трассировщик,
откройте Interpreter.cpp. Использование Форта здесь оправдано,
поскольку его виртуальная машина более приспособлена для
работы на небольших устройствах, и кроме того писать вручную
на Форте гораздо удобнее, чем на байт-коде ActionScript.


По команде перехода назад определяется начало цикла. Если
количество итераций превышает пороговое значение,
объем кода не слишком велик(MAXTRACE=2000 в текущей
реализации), при трассировке не встречается "запрещенных"
инструкций, то строится очередное дерево. Его корень это
начало цикла, а листья это переходы в корень дерева.
Дерево строится "лениво", по мере нахождения альтернативных
путей в цикле оно недетрминированно расширяется.
По поводу Вашего вопроса. Байт-код abc это данность с которой
разработчики вынуждены мириться. Повторюсь, вся система
уже работает на уровне байт-кода, а динамическая компиляция
производится в целевой машинный код. FVM работает на нижнем
уровне, "прозрачно" для пользователя abc-кода.

pingback: http://flash-ripper.com/archives/002124.php

Tamarin Build Documentation: http://developer.mozilla.org/en/docs/Tamarin_Build_Documentation