Barrapunto

Disculpas aceptadas, pelillos a la mar.

Supongo que cuando tenga tiempo (estoy en pleno proceso de revisión de mi tesis, de ahí que esté despierto a estas horas) me pasaré a ver si puedo ayudar con la máquina virtual.

Solo te contestaré por aquí, que no se puede hablar de portabilidad ni abstracción si dependéis de que el host os de direcciones de 32 bits. No sé qué haréis con los load/store de la máquina virtual, si los lanzáis en crudo (lo que me parecería un error irremediable) o qué, pero traducir un load/store de 32bits a un equivalente del host en 64bits cuesta 0, y vuestra máquina se vuelve compatible con hosts de 64bits (y 1000bits). Tendría que ver el motor de traducción de instrucciones que tenéis, pero sigo sin entender por qué dices que no es posible. Si tengo que traducir un load de 32 bits a un mov de x86, puedo con el mismo esfuerzo traducirlo a un mov de x86-64. La verdad es que tengo varias posibilidades de lo que puede que tengáis implementado en la cabeza, y varias soluciones para cada una de ellas; el caso es que no veo que sea imposible. La única forma en la que vería imposible solucionarlo es que las instrucciones de acceso a memoria fuesen crudas y se ejecutasen sin traducir (algo raro, retorcido y que no aporta nada).

En cualquier caso, para la próxima, mejor una máquina virtual de pila. Parece una tontería, pero ya no tienes que tener en cuenta este tipo de cosas de forma específica.

Un saludo.

prometi que no iba a responder, cierto... :)

creo que existe una equivocacion, esto no es una maquina virtual de x86 o de un procesador conocido, es una maquina virtual como lo es lua, no hay la traduccion que dices, esto es una maquina de pila, solo que los elementos de la pila y las unidades que se compilan generan valores y codigos (no codigos nativos) de 32bits. Yo no dije que no se puede, sino que esta pensando en instrucciones de 32bits, no es una falla de diseño, porque cuando esto se creo no existian procesadores de 64bits por lo menos no a nivel del usuario normal, y para mantener la compatibilidad se sigue manteniendo la filosofia de 32bits (ahora se entiende lo de "filosofia"?). Como dije, no es que no se pueda hacer, sino que requiere un cambio que implicaria romper compatibilidad hacia atras. Para explicarte un poco mas, bennugd es un conjunto de 2 utilidades, mejor dicho 3, 1) un compilador que genera a partir de un codigo legible un codigo binario con opcodes de la VM y otra info adicional. 2) una libreria, que es la VM, y puede ser usada como engine scripting en cualquier lenguaje, como lo es lua o python. 3) un interprete o ejecutor, que lo unico que hace es llamar a las funcione de carga del binario compilado y luego llamar a las funciones de ejecucion de la VM (ambas funciones se encuentran en la libreria del punto 2).
No es que no compile ni que no funcione en 64bits, de hecho varios la han probado y compilado y dicen que funciona perfectamente en 64bits, pero tanto Miriam como yo, tenemos dudas de que no pueda dar algun problema si alguna direccion alocada da un valor mas alla de lo que puede contener un dato de 32bits y se intenta almacenar en un registro de 32bits.
Repito, esto es una maquina virtual como lo es lua o python y asi como estos, no se virtualiza la memoria ni los dispositivos.
Con respecto a la portabilidad, no es un deseo o sueño, bennugd corre en diversas plataformas, oficialmente estan pc (win/linux en sus variantes), wiz (arm), y hay versiones casi-oficiales que solo se limitan en compilar el proyecto (con cambios menores como algun include extra y cosas asi) y estan corriendo en WII, MAC, GP2X, dingoo, y muchas otras plataformas.
Espero ahora haya podido explicar un poco mas del asunto.
Cordiales saludos.