Существует ли альтернатива байткоду?

[ilovb]

Известно что используя байткод как промежуточное представление можно компилить код на целевой машине. И это конечно гуд, т.к. можно учитывать особенности архитектуры (да и другие плюшки тоже есть) Кроме того с помощью байткода можно предоставить единую среду для разных языков. Тот же .NET например.

Можно ли все это получить без байткода?

Михаэль Франц предлагал использовать дерево:

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

http://oberon2005.oberoncore.ru/paper/obe_java3.pdf
Но как известно оно не стрельнуло.
Тем более я не представляю может ли это дерево быть единым для многих языков как байткод.

[Губанов Сергей Юрьевич]

В дотнете не байткод. Дотнетный IL достаточно высокоуровневый для того чтобы дать JIT компилятору информацию для оптимизации генерируемого машинного кода. У Франца претензия ко всяким байткодам только в этом и состояла. То есть этот вопрос снят полностью.

А использовать для хранения дерево или линейную структуру это немного другой вопрос.

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

[valexey]

В дотнете не байткод. Дотнетный IL достаточно высокоуровневый для того чтобы дать JIT компилятору информацию для оптимизации генерируемого машинного кода. У Франца претензия ко всяким байткодам только в этом и состояла. То есть этот вопрос снят полностью.

Тогда в jvm тоже нет байткода! Потому, что java-файл (исходник на java) с точностью до дженериков (которые на поведение не влияют) восстанавливается из class-файла (результата компиляции). То есть вся высокоуровневая информация таки никуда не девается. Ну и да, информации JIT-компилятору вполне хватает для оптимизаций.

[valexey]

Тем более я не представляю может ли это дерево быть единым для многих языков как байткод.

А я не представляю как оно может быть единым для многих языков. Оно по определению заточено под один конкретный язык.

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

[ilovb]

В дотнете не байткод. Дотнетный IL достаточно высокоуровневый для того чтобы дать JIT компилятору информацию для оптимизации генерируемого машинного кода. У Франца претензия ко всяким байткодам только в этом и состояла. То есть этот вопрос снят полностью.

А использовать для хранения дерево или линейную структуру это немного другой вопрос.

Да, я не точно выразился. Я под термином "байткод" подразумеваю именно линейную структуру команд некой абстрактной машины. Это слово использовал только потому что не знаю единого термина. А термин "IL" у всех сразу с .NET ассоциируется.

[ilovb]

Тем более я не представляю может ли это дерево быть единым для многих языков как байткод.

А я не представляю как оно может быть единым для многих языков. Оно по определению заточено под один конкретный язык.

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

Вот и я также думаю. Заради этого и поднял эту тему. 
Получается что байткод абстрактная машина - это единственный способ предоставить единую среду.

С другой стороны не менее любопытно следующее:
Что если использовать что-то вроде дерева Франца для семейства языков. У которых единая база. Например набор ускоспециализированных Оберонов. Один для созидания общей архитектуры приложения, другой для низкоуровневого кодинга, третий для удобства математических построений...

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

"Разделяй и властвуй!" как говорится 

В Zonnon вот напихали свистоперделок... и сделали турбо паскаль какой-то...

[Valery Solovey]

Дерево, видимо, удобнее если при загрузке модуля генерировать для него сразу весь машинный код (включая код для процедур, которые фактически могут ни разу не вызываться) -- так делается в Обероне. В дотнете наоборот, там JIT компилятор компилирует в машинный код только те процедуры, которые реально используются (компиляция процедуры осуществляется при первом к ней обращении), поэтому уместа линейная структура, а не дерево.

По моему дилетантскому мнению, для компиляции произвольных кусочков класса или модуля дерево удобнее. Или я что-то упускаю?

[Valery Solovey]

Что если использовать что-то вроде дерева Франца для семейства языков. У которых единая база.

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

[Губанов Сергей Юрьевич]

Подозреваю, что здесь слово "дерево" было использовано как минимум в двух смыслах:

1) Дерево синтаксического разбора.
2) Францевское дерево специальной архивации/разархивации кода (чтобы бинарники были очень маленькими).

Так вот архивировать код для того чтобы потом его можно было быстро загрузить в ОЗУ с жёсткого диска при современных скоростях работы жёстких дисков уже не актуально.

[ilovb]

А разве архивация в дереве Франца - это не просто дополнительная плюшка?

Формат представления кода Juice, который мы называем  "тонкие бинарники" (slim binaries) [2],
опирается на результаты диссертационной работы Михаэля Франца [4].  Формат тонких
бинарников значительно отличается от представления,  характерного для виртуальных машин,
такого как P-код [12] или байт-код Java [8]. В нем не хранится исполняемый код. Вместо этого
Juice-формат опирается на древовидное представление программы в том виде  (синтаксические
деревья),  который обычно порождается оптимизирующими компиляторами.  Это промежуточное
представление затем упаковывается путем слияния изоморфных поддеревьев с использованием
классического LZW-алгоритма  (вариант Уэлша) [15],  адаптированного специально для сжатия
деревьев программного кода.  За счет специфики он позволяет добиться значительной степени
компактности кода (рис. 2).
Использование древовидного промежуточного кода имеет тот недостаток,  что оно не пригодно
для процесса интерпретации.  В то же время такие форматы,  как P-код и байт-код Java,
позволяют использовать прямой доступ, например, позволяют переместиться на 20 инструкций и
продолжить интерпретацию кода. В случае тонких бинарников это невозможно. Каждая лексема
("слово языка")  в Juice-формате может интерпретироваться лишь в контексте всех тех лексем,
которые ей предшествуют. По этой причине наша реализация избегает проведения интепретации
промежуточного кода с самого его начала и использует встроенный механизм генерации кода на
лету [4,5].
С другой стороны,  при считывании тонких бинарников наша система восстанавливает
первоначальную древовидную структуру, которая не только идеально подходит для проведения
оптимизирующей генерации кода,  но и также позволяет относительно просто проводить
верификацию кода.  Дело в том,  что формат тонких бинарников сохраняет всю информацию о
структуре  (в частности,  потоки управления и области видимости переменных),  тогда как при
переходе к линеаризированной форме  (как в случае байт-кода Java)  эта информация попросту
теряется.  Поэтому для того чтобы провести генерацию машинного кода из байт-кода Java  с
привлечением передовых методов оптимизации,  необходимо затратить немало времени на
восстановление утраченной информации. В случае Juice-кода этого делать не надо. То же самое
справедливо и в отношении верификации кода:  гораздо проще осуществлять анализ.
...
Наша нынешняя реализация тонких бинарников несколько ограничена, поскольку поддерживает
только один язык — Oberon.  В этом смысле наша система сейчас ничем не лучше схем
переносимости, построенных на основе абстрактных машин,  где набор инструкций виртуальной
машины специально подбирается для поддержки конкретного языка программирования. В то же
время мы не видим никаких принципиальных трудностей в плане построения упакованных
синтаксических деревьев для других языков,  быть может,  даже с использованием в точности
такого же Juice-формата.  Ведь специфика языка задается лишь на стадии фактической
реализации.

http://oberon2005.oberoncore.ru/paper/obe_java4.pdf

Сама по себе архивация кода мало интересна, да.

[ilovb]

Интересно, а есть ли исследования на тему плюсов/минусов абстрактных машин, кроме работы Франца?

Поделитесь ссылками плиз если кто знает.

[Губанов Сергей Юрьевич]

А разве архивация в дереве Франца - это не просто дополнительная плюшка?

Как бы благодаря этой плюшке Франц осуществлял кодогенерацию на лету, то есть быстрее чем читал файл с жёсткого диска. Убери эту плюшку и что останется от Франца? Обыкновенное синтаксическое дерево.

[Губанов Сергей Юрьевич]

Именно, что когда он читал и десериализовывал своё дерево с жёсткого диска, для уже прочитанных ветвей машинный код уже был сгенерирован и теперь если встречалась ветка "повторного использования кода", то машинный код для неё подставлялся уже готовенький, что и обеспечивало кодогенерацию "на лету". В этом суть дерева Франца. Без этой фишки дерево становится обыкновенным -- не Францевским.

[ilovb]

Да, наверно вы правы.

[ilovb]

Я так понимаю, что лучше байткода на сегодня ничего не придумали.