Barrapunto

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.

Tiene que haberla, en algún momento. Si tienes instrucciones no nativas y un procesador nativo, tiene que haber una traducción de no-nativo a nativo. Igual es que me he explicado mal.

Pero siguen sin ser nativas, así que no influye en qué "lenguaje" esté escrito el intérprete de bytecode.

Sigues hablando de dos niveles de instrucciones, los del host y los del guest, y hablas de no romper la compatibilidad hacia atrás del guest por cambiar el host, lo cual no tiene por qué ser así.

Luego, como te decía, no hay ningún problema en hacer una máquina virtual para 64 bits. Al menos la Wii es de 64 bits, y la GP2X hasta es ARM y todo. No sé qué os pone tan nerviosos de que os devuelvan una dirección de con bits activos en la parte superior de la palabra de 64bits, solo tenéis que enmascararlos cuando lo paséis a la máquina de pila y reestablecerlos cuando haya que traducir a código nativo; la traducción de instrucciones la vais a hacer de todos modos. Esto ocurre en la máquina virtual de java, y supongo que en la de python y la de lua también.

En fin, sin ver el código no puedo entender bien qué os da miedo de las direcciones de 64bits. No veo que tenga que haber ningún problema. Como te digo, cuando tenga tiempo le echaré un ojo. Pero sí me has dado muchos más datos técnicos (algunos me confunden, si te soy sincero, porque no entiendo bien en qué influyen en el asunto, supongo que se me escapa algo que no me cuentas) y ha quedado todo más claro, gracias. Pero sigo estando en desacuerdo en que haya ningún problema con portar la MV a 64bits (sin destruir ningún tipo de compatibilidad hacia atrás).

Un saludo.