WoL Virtual - это виртуальный язык программирования, созданный для создания под него компиляторов (трансляторов).
WoL VM - среда исполнения (интерпретатор) WoL Virtual в нативном виде или в виде байт-кода.
Больше информации о WoL Virtual -> http://www.wolnew.wordpress.com/wol-virtual/
Больше информации о WoL VM -> http://www.wolnew.wordpress.com/wolvm/
Репозитории на гитхабе
  https://github.com/snaulX/virtual-machine-dotnet
  https://github.com/world-of-legends/virtual-machine-jvm
  https://github.com/world-of-legends/virtual-machine-native

dll - библиотеки только под win. Удобно наверно поддерживать три кодовые базы (обещая версию на python и прочее), вместо использования... впрочем, неважно. Теперь представь кто будет писать "vm библиотеку" под все эти платформы, кроме тебя. Хотя, зачем я ищу логику, если ты пишешь три виртуальные машины (две из которых на vm) и язык для вм с ручным управлением памятью, чтобы написать другой язык, чтобы на нем написать что-то...

На сколько я знаю, если писать на каком-нибудь c++ или вообще любом нативном языке и компилировать его в dll, то эту dll можно использовать почти на любой ос. На самом деле когда я писал про питон у меня был человек который хотел помочь с написанием вм но только на питоне, правда потом он отказался от этой идеи, а сам я если и напишу питоновскую версию то до этого момента ещё ооооооооочень далеко (пойду уберу из статьи обещание про питон). Писал я под три кодовые базы, а не например сразу под нативную, потому что под каждую платформу используются свои технологии => ты же не будешь писать например JavaFX приложение под LLVM или ASP.NET приложение используя JVM и тд.
Про фреймворки: так как под каждую платформу используются своя технология, то и естественно фреймворки будут писаться только один раз (не считая базовых случаев, где фреймворки используются для работы с консолью, потоками и тд). Объединённость достигается на высоком уровне (не в вм). Например пример куска кода библиотеки (не для вм) написанного на высокоуровневом яп:
язык для вм с ручным управлением памятью, чтобы написать другой язык, чтобы на нем написать что-то...Изначально я хотел написать самый обычный интерпретатор, но потом я понял, что у меня будут огромные проблемы со скоростью выполнения и памятью и тогда я решил что мне нужна вм под которую я буду компилировать, для того, чтобы компилятор оптимизировал исходный код, а вм исполняла уже совсем лёгкий для НЕЁ код. Я сначала пытался найти документацию или статьи к LLVM или JVM или .NET, но почти ничего не нашёл, а если что-то и находил, то мне для разработки не совсем удобно было разрабатывать под них и тогда я решил сделать свою. Также я понял, что если другие разработчики компиляторов столкнуться с такой же проблемой, то можно представить свою вм "общественности", чтобы им было удобнее писать компиялторы.
Ну в принципе всё, те кто не считают мою идею сумасшедшой, то я буду рад если вы мне поможете, а если считаете - то объясните почему и предложите варианты решения получше, я буду только рад

Нет, dll - формат библиотек, собранных под винду. С релизом NET Core появилась возможность компилировать либы в его байткод и запускать через dotnet, как я понял.
Что ты собрался оптимизировать перед интерпретацией кода для вм, работающей на вм? Самая важная оптимизация заключается в jit/aot для таких платформ, иначе они работают в сотни раз медленнее, сомневаюсь что этой штуке будет норм с твоим байткодом сверху. Писать генератор для CLR/JVM глупость, потому что оптимизировать свой код лучше, чем C# чужой, ты никогда не сможешь. Следовательно, чтобы компилятор оптимизировал код, нужно делать транспиляцию в язык для виртуальной машины (не твой компилятор, не твой язык и не твоей виртуальной машины). Это наиболее эффективно по производительности, проще всего в реализации и дает хорошую интеграцию с экосистемой языка. Например Haxe позволяет работать со стандартной библиотекой C#/Java и предоставляет автокомплит через чтение class/dll, большая часть типов совместимы, можно делать вставки на самих языках. Никакой боли и оверхеда от контактирования с какой-либо кастомной вм поверх, учитывая что ты имеешь три разных кодовых базы для нее - стабильности это тоже не добавляет.
LLVM, C/Cpp - самые нормальные варианты для написания языков из перечисленного. Тебе просто не интересно разбираться в чем-то чужом, поэтому ты и ковыряешься над виртуалкой. По этой же причине и "другим разработчикам компиляторов" это не будет интересно. Стоило бы сосредоточиться на идее языка, ради которого это все делается. Покрывает ли он какие-то цели лучше других, или это все ради самообразования? Еще лучше будет позаниматься некоторое время на чем-то не c-like, наверно.

Евангелист хакси в треде
RblSb, вполне дельные советы даешь, очень даже.
Тебе просто не интересно разбираться в чем-то чужом, поэтому ты и ковыряешься над виртуалкой. По этой же причине и "другим разработчикам компиляторов" это не будет интересно. Стоило бы сосредоточиться на идее языка, ради которого это все делается. Покрывает ли он какие-то цели лучше других, или это все ради самообразования?но думается мне, автор все это по фану затеял, а ты все портишь.

Это вам не браузер текстовый писать!

Залил релиз 0.8.1 -> https://github.com/snaulX/virtual-machine-dotnet/releases/tag/0.8.1
Очень многое добавил и поменял. Документацию пока пишу (https://github.com/snaulX/virtual-machine-dotnet/wiki), а пока можете позапускать примеры.
А я также нашёл статьи по написанию компиляторов Brainfuck под .Net, jvm и llvm) И сейчас занимаюсь написанием компилятора моего нормального языка под .NET
Можете посмотреть презентацию моего проекта, но там почти никакой особо важной информации нет, так как готовил её к конкурсам и конференциям и в основном всё рассказывал, а не показывал на презентации -> https://docs.google.com/presen...PhM/edit?usp=sharing

snaulX, ты говоришь о кросспатформенности, но в презентации у тебя везде exe и dll. Кроме JVM на линуксы что-то стоит ждать?

aNNiMON, так как LLVM изначально компилирует в объектный файл (*.o) а только затем помощью gcc мы компилим в исполняемый файл. В статье, которой я нашёл (https://habr.com/ru/post/342456/) в приведении примера компиляции кода был использован bash, так что можно ждать ещё и LLVM.