Ничего не могу найти, удовлетворяющее моим требованиям. Итак, что хотелось бы:
Высокая скорость работы;
Возможность переопределить функции работы с памятью;
Возможность вызывать нативные функции из виртуальной машины;
Чистый Си без каких-либо внешних зависимостей;
Хотя бы минимальные проверки обрабатываемых инструкций на безопасность;
Как можно меньший размер.
А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.
Здравствуйте, kaa.python, Вы писали:
KP>Ничего не могу найти, удовлетворяющее моим требованиям. Итак, что хотелось бы:
KP>
KP>Высокая скорость работы; KP>Возможность переопределить функции работы с памятью; KP>Возможность вызывать нативные функции из виртуальной машины; KP>Чистый Си без каких-либо внешних зависимостей; KP>Хотя бы минимальные проверки обрабатываемых инструкций на безопасность; KP>Как можно меньший размер. KP>
KP>А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.
Здравствуйте, kaa.python, Вы писали:
KP>Хотелось бы именно виртуальную машину, а не интерпретатор.
Еще очень легкая виртуальная машина у Caml Light, но получится ли это всунуть в
драйвер не знаю, ну и целевой ML образный язык тоже может не понравится.
Здравствуйте, kaa.python, Вы писали:
KP>Ничего не могу найти, удовлетворяющее моим требованиям. Итак, что хотелось бы:
KP>
KP>Высокая скорость работы; KP>Возможность переопределить функции работы с памятью; KP>Возможность вызывать нативные функции из виртуальной машины; KP>Чистый Си без каких-либо внешних зависимостей; KP>Хотя бы минимальные проверки обрабатываемых инструкций на безопасность; KP>Как можно меньший размер. KP>
KP>А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.
А LLVM не устраивает только по размеру или еще по чему нибудь?
<Подпись удалена модератором>
Re: Разыскивается легкая виртуальная машина
От:
Аноним
Дата:
03.09.12 17:10
Оценка:
Здравствуйте, kaa.python, Вы писали:
KP>Ничего не могу найти, удовлетворяющее моим требованиям. Итак, что хотелось бы:
KP>
KP>Высокая скорость работы; KP>Возможность переопределить функции работы с памятью; KP>Возможность вызывать нативные функции из виртуальной машины; KP>Чистый Си без каких-либо внешних зависимостей; KP>Хотя бы минимальные проверки обрабатываемых инструкций на безопасность; KP>Как можно меньший размер. KP>
KP>А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.
KP>А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.
Пока не до читал до драйвера почему-то подумал что тебе нужно что-то типа qemu )))). Но таки, почему бы и не заюзать что нить типа MIPS симулятора? Их много, твоим требованиям такой финт ушами вроде отвечает. Да и код для VM можно компилировать штатным компилятором.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Пока не до читал до драйвера почему-то подумал что тебе нужно что-то типа qemu )))). Но таки, почему бы и не заюзать что нить типа MIPS симулятора? Их много, твоим требованиям такой финт ушами вроде отвечает. Да и код для VM можно компилировать штатным компилятором.
Да мне нужно что-то совсем мелкое и легкое. Задача довольно проста — есть код обрабатывающий определенные события написанный на специальном языке. Надо это дело оттранслировать в промежуточную форму (интерпретировать в ядре, все же, более опасно) и выполнить это дело.
Здравствуйте, FR, Вы писали:
FR>Еще очень легкая виртуальная машина у Caml Light, но получится ли это всунуть в FR>драйвер не знаю, ну и целевой ML образный язык тоже может не понравится.
Язык уже есть, так что нужна RISC, CISC или стековая машина с простым и понятным набором инструкций.
Здравствуйте, FR, Вы писали:
FR>Посмотри NekoVM. FR>Я сам правда ее только мельком видел, так что возможно и не совсем то что нужно, но штука очень легкая.
Похоже что тоже не то. Странно, но видимо у меня совсем уж уникальная хотелка
Здравствуйте, kaa.python, Вы писали:
KP>Язык уже есть, так что нужна RISC, CISC или стековая машина с простым и понятным набором инструкций.
Я понял что нужна более высокоуровневая VM, а так получается же шило на мыло, или нужна кроссплатформенность?
Попробуй копать в сторону Forth, простую форт машину, даже кроссплатформенную, на шитом коде, несложно сделать.
Здравствуйте, FR, Вы писали:
FR>Я понял что нужна более высокоуровневая VM, а так получается же шило на мыло, или нужна кроссплатформенность?
Шило на мыло — это что в сравнении с чем?
FR>Попробуй копать в сторону Forth, простую форт машину, даже кроссплатформенную, на шитом коде, несложно сделать.
Да простую RISC машину тоже очень легко сделать, там же команд раз-два и обчелся. Просто думал может уже что-то готовое есть.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, FR, Вы писали:
FR>>Я понял что нужна более высокоуровневая VM, а так получается же шило на мыло, или нужна кроссплатформенность?
KP>Шило на мыло — это что в сравнении с чем?
По сравнению с интепретаторами. Может, просто tinytcl допилить и всосать?
Здравствуйте, denisko, Вы писали:
KP>>Шило на мыло — это что в сравнении с чем? D>По сравнению с интепретаторами. Может, просто tinytcl допилить и всосать?
Основной минус интерпретаторов — они задают определенный синтаксис языка. Будь то TCL, будь то ML или еще что-то. Кроме того, они усложняют проверку на потенциальные ошибки в коде за счет более сложных операций. Поэтому, мне бы хотелось именно чистую (или как ее еще назвать) виртуальную машину.
Здравствуйте, kaa.python, Вы писали:
FR>>Я понял что нужна более высокоуровневая VM, а так получается же шило на мыло, или нужна кроссплатформенность?
KP>Шило на мыло — это что в сравнении с чем?
По сравнению с высокоуровневыми ВМ, если нет требований кроссплатформенности,
то по моему вместо низкоуровневых проще сразу грузить целевой машинный код,
который для верификации компилировать в песочницу например типа гугловского
Native Client.
При таком подходе сразу встает следующий вопрос. Как скомпилировать некую пользовательскую функцию в целевой машинный код и без особо серьезных приседаний вызвать ее в требуемом месте?
Например, у нас есть заданная пользователем функция:
int foo(int a, int b)
{
return a+b;
}
Да, я могу ее собрать при помощи LLVM и даже выполнить. Остается самая малость — как передать эту фунцию в виде целевого машинного кода в другой процесс и выполнить уже там?
Здравствуйте, kaa.python, Вы писали:
KP>Да, я могу ее собрать при помощи LLVM и даже выполнить. Остается самая малость — как передать эту фунцию в виде целевого машинного кода в другой процесс и выполнить уже там?
Т.е. задача — выполнять в ядре пользовательский код? Мсье понимает...
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, kaa.python, Вы писали:
KP>Да, я могу ее собрать при помощи LLVM и даже выполнить. Остается самая малость — как передать эту фунцию в виде целевого машинного кода в другой процесс и выполнить уже там?
Такую простую функцию, без внешних зависимостей легко, компилируем как position-independent code (-fPIC) в
память, тот же clang должен это уметь.
Вот зависимости да придется как-то разруливать в динамике.
Проще по моему не использовать отдельные функции, а грузить готовые пакеты/модули/плагины тот же
Native Client всю необходимую инфраструктуру представляет.
