programacion - programar pic16f887 en c
¿Una VM limpia e independiente implementada en C y con un tamaño de código compilado inferior a 100-200K? (7)
En opción es usar algo mínimo y extenderlo. mini-vm tiene menos de 200 líneas de código, incluidos los comentarios, tiene una licencia liberal (MIT), está escrito en C. Fuera de la caja admite 0 operaciones, pero es muy fácil de extender. El compilador de ejemplo incluido es solo una calculadora simple. Pero uno podría imaginar fácilmente agregar comparaciones, sucursales, acceso a la memoria y llamadas de supervisor para llevarlo a donde quiera ir. Una máquina virtual que sea fácil de ampliar es especialmente útil para desarrollar lenguajes específicos de dominio, y tener múltiples idiomas dirigidos a su versión de mini-vm sería más sencillo que tener que implementar múltiples compiladores (o portarlos. El compilador de QuakeC es simplemente lcc, y muy facil de retarget).
El soporte de subprocesos tendría que ser una extensión, y la máquina virtual central no funcionaría bien en un escenario pthread multiprocesador (subprocesos pesados). Extrañamente, mini-vm puede tener una PC (contador de programas) por subproceso pesado, pero compartiría registros entre todos los subprocesos utilizando el mismo contexto. Sin embargo, ejecutar contextos separados sería seguro para subprocesos.
Me estoy saltando respondiendo a los requisitos del idioma porque la pregunta comienza con una máquina virtual de barebones. Pero al mismo tiempo exige una sintaxis similar a la de C / Java, no estoy seguro de cómo resolver ese conflicto aparte de declarar este conflicto.
Estoy buscando una máquina virtual con las siguientes características:
- Huella de código compilado pequeño ( bajo 200K ).
- No hay dependencias externas.
- Compatibilidad con cadenas Unicode (o sin formato).
- Código limpio / bien organizado.
- Código C (99) , NO C ++.
- C / sintaxis similar a Java .
- Operadores / bitwise: Y / O, etc.
- Soporte de roscado .
- Código de bytes genérico / portátil . Bytecode debería funcionar en diferentes máquinas, incluso si se compiló en una arquitectura diferente con diferente endianness, etc.
- Barebones , nada lujoso necesario. Sólo el soporte de lenguaje básico.
- Lexer / parser y compilador separado de VM . Incorporaré la máquina virtual en un programa y luego compilaré el código de bytes de forma independiente.
Hasta ahora he revisado Lua , Squirrel , Neko , Pawn , Io , AngelScript ... y el único que se acerca a la especificación es Lua, pero la sintaxis es horrible, no tiene soporte a nivel de bits y el estilo del código generalmente apesta. Squirrel y IO son enormes, en su mayoría. El peón es problemático, es pequeño, pero el bytecode no es multiplataforma y la implementación tiene algunos problemas serios (el bytecode no está validado en absoluto, ni siquiera los encabezados AFAIK).
Me encantaría encontrar una opción adecuada por ahí.
¡Gracias!
Actualización: los intérpretes de Javascript son ... intérpretes. Esta es una pregunta de máquina virtual para una máquina virtual basada en bytecode, por lo tanto, el requisito de separación compilador / bytecode vm. JS es interpretado, y muy raramente compilado por JIT. No quiero JIT necesariamente. Además, todos los analizadores ECMAScript actuales son todos menos pequeños.
Finalmente, después de todo este tiempo, ninguna de las respuestas realmente lo hizo. Terminé de bifurcar a LUA. A partir de hoy no existe una VM autocontenida con los requisitos anteriores ... es una lástima;
No obstante, Pawn es bastante bueno, aunque solo el código no fuera un poco problemático.
Intente incrustar un intérprete de JavaScript en su código.
Para algo muy "barebones":
http://en.wikibooks.org/wiki/Creating_a_Virtual_Machine/Register_VM_in_C
Más de una breve introducción al tema que cualquier otra cosa, concedida.
Sin embargo, es probable que cumpla al menos con algunos de los criterios deseados:
- Huella de código compilado pequeño (bajo 200K) ... cheque, obviamente;
- No hay dependencias externas ... cheque;
- Código limpio / bien organizado ... cheque;
- Código C (99), NO C ++ ... cheque;
- C / Java como sintaxis ... cheque.
Prueba EmbedVM.
http://www.clifford.at/embedvm/
http://svn.clifford.at/embedvm/trunk/
Aquí hay un ejemplo de un código, un juego de adivinanzas. El compilador está construido en C con lex + yacc:
global points;
function main()
{
local num, guess;
points = 0;
while (1)
{
// report points
$uf4();
// get next random number
num = $uf0();
do {
// read next guess
guess = $uf1();
if (guess < num) {
// hint to user: try larger numbers
$uf2(+1);
points = points - 1;
}
if (guess > num) {
// hint to user: try smaller numbers
$uf2(-1);
points = points - 1;
}
} while (guess != num);
// level up!
points = points + 10;
$uf3();
}
}
No hay ningún soporte de subprocesos. Pero no hay un estado global en la máquina virtual, por lo que es fácil ejecutar varias copias en el mismo proceso.
La API es simple. VM RAM se accede a través de devoluciones de llamada. Su bucle principal llama a embedvm_exec(vmdata) repetidamente, ejecuta una sola operación y regresa.
La máquina virtual tiene una huella muy pequeña y se ha utilizado en microcontroladores de 8 bits.
NekoVM que ha revisado NekoVM , pero no menciona por qué no es adecuado para usted.
Está escrito en C, no en C ++, la VM está por debajo de 10kLOC con un tamaño compilado de aproximadamente 100kB, y el compilador es un ejecutable separado que produce un bytecode portátil. El lenguaje en sí tiene una sintaxis tipo C, operadores bitwise y no es hostil para subprocesos.
- Requiere menos de 64 KB de RAM
- ~ 160 KB de tamaño binario
- escrito en C99
- Basado en VM
- tiene precompilación bytecode
IoT JavaScript JerryScript con libuv (estilo nodejs) - puede ser más fácil jugar con él.
El enhebrado probablemente no esté allí en el estado que deseas. Hay adiciones recientes a ECMAScript en torno a los trabajadores de fondo en hilos separados y búferes de JerryScript compartidos compartidos (no estoy seguro de cuál es la historia con JerryScript . Probablemente aún no haya llegado a ese punto, pero quién sabe, tienen un plan para hacerlo. no estar lejos