Ver la versión completa : Pregunta para una-i sobre dynarec.
Bueno le preugnto a unai porque no se a quien mas preuntar.
Si tenemos una chache de N bloques, cada bloque tiene el
codigo generado para ese opcode + PC + ciclos
+ avance en bytes del PC si la maquina objetivo es CISC
aunque tembien lo podemos incrementar en el codigo generado.
¿Vamos que cada bloque solo tiene el equivalente a un opcode
con acceso constante tipo tabla hash?
Porque hay que manejar las interrupciones, excepciones y demas...
Esto con un control de las intrucciones mas usadas ya
producira un incremento de rendimiento.
Lo que no comprendo es porque generais codigo para
las instrucciones de salto ¿Es mas rapido que interpretadas?
Otra cosa es si...
¿haceis un control al codigo que se modifica a si mismo?
¿Esto disminuye mucho el rendimiento del sistema?
Ya ta... [Ahhh].
Aver ando un poco pillado asi que te respondo en telegrama:
* El recompilador no recompila intruccion por intruccino eso es muy lenot, genera bloques de "ejecucion" de digamos unos 500 ciclos.
* Nos has ningun mapa ni nada si no un "mapa de memoria recompilada" cada vez que se va a salir de un bloque para entrar en otro se mira el PC de la psx y se acede a "un array muygrande" que tiene un puntero al bloque que comienza en esa direccion.
este array es mas o menos de 2mb
* Lo de lso saltos ahora te quedar amas claro, dependidneod del recompilado r los saltos se recompilas o se "interrumpe" la recompilacion cada vez que se llega a un salto.
* Ese mismo "array de bloques compilados" se "marca" con cada aceso a memoria "invalidado" la cache de codigo y por tanto soportando codigo "automodificable" en cierta medida, esl soporte de codigo automodificable "generico" es mas complicado... y croe uq en el caso de la psx no sera necesario, de hecho es másqu e provable que el soporte de codigo automodificable sea un parametro que se pueda configurar por juego.
Esto es mas o menos todo lo que creo que me preguntabas... si no pues preguta otra vez :P
Unai.
Aver ando un poco pillado asi que te respondo en telegrama:
* El recompilador no recompila intruccion por intruccino eso es muy lenot, genera bloques de "ejecucion" de digamos unos 500 ciclos.
* Nos has ningun mapa ni nada si no un "mapa de memoria recompilada" cada vez que se va a salir de un bloque para entrar en otro se mira el PC de la psx y se acede a "un array muygrande" que tiene un puntero al bloque que comienza en esa direccion.
este array es mas o menos de 2mb
* Lo de lso saltos ahora te quedar amas claro, dependidneod del recompilado r los saltos se recompilas o se "interrumpe" la recompilacion cada vez que se llega a un salto.
* Ese mismo "array de bloques compilados" se "marca" con cada aceso a memoria "invalidado" la cache de codigo y por tanto soportando codigo "automodificable" en cierta medida, esl soporte de codigo automodificable "generico" es mas complicado... y croe uq en el caso de la psx no sera necesario, de hecho es másqu e provable que el soporte de codigo automodificable sea un parametro que se pueda configurar por juego.
Esto es mas o menos todo lo que creo que me preguntabas... si no pues preguta otra vez :P
Unai.
Muchas gracias maquina ahora todo encaja.
Vamos, que tu recompilas toda la memoria principal bicho xD.
Yo había visto otra cosa mas refinada y mas lenta
para maquinas objetivo con mucha memoria.
Mira esto es lo que estaba mirando yo.
http://img114.imageshack.us/img114/9500/sdsrj2.png (http://imageshack.us)
Y esto lo que creo que tu haces.
http://img145.imageshack.us/img145/3844/sds2sq9.png (http://imageshack.us)
LOL [Ahhh].
A reimplementar todo lo que llevo me toca.
Muchas gracias maquina ahora todo encaja.
jeje tampoco es pa tanto...
Vamos, que tu recompilas toda la memoria principal bicho xD.
Bueno toda no solo la que se ejecuta.
Hombre eso es un poco lo de menos se pude hacer sencillo tambien...
recompilar un bloqu solo al cabo de n ejecuciones y de mientras interpretarlo...
las dos alternativas son muy similares... lo queno se es de donde habias sacado lo de recompiar solo una instruccion..
A reimplementar todo lo que llevo me toca.
Jejeje la practica conduce a la perfecion :P
Unai.
Tampoco tienes que responderme tan pronto no hay ninguna prisa :brindis:. En relidad me haces un favor [wei].
Resumiendo lo dicho:
http://img246.imageshack.us/img246/5864/dynarecdm5.png (http://imageshack.us)
Que bien dibujo, leches :D.
Estos de Microsoft xD no había caido en que permite
apuntar el PC a un segmento con espacio reservado con malloc.
Ahora las preguntas que me pudren por dentro:
- ¿Como se estima cuanto espacio hay que reservar de
memoria de codigo a generar por el traductor?
- Y mas importante aún, ¿Como estimar el espacio entre
bloques de codigo de traducción?
Estos pueden resultar preguntas tontas para quien ya
tenga esas partes hechas, pero no me aclaro y en los codigos
que he buscado no encuentro la respuesta a esto, debo
estar pensado en el tema de forma erronea...
Lo de la tabla de saltos tienes la razón,
sino es imposible saltar por el codigo generado...
Me autoflagelo... [propeller]
Otra es la tabla de saltos, que para sistemas con poca
memoria esta bien, pero con sistemas con mas memoria como
la neogeo con la MEM del M68k con 24 bits de bus de datos
no me encaja...[Ahhh]?! :D
Supongo que cada cache_entry puede tener su tabla de
saltos relativos.
* Ummm, lo del malloc es posible que lo que tengas que hacerle es un mmap para cambiarle los atributos de ejecucion o algo asi...
* El tamaño del codigo recompilado no lo sabes, lo que se suele hacer es tener un "bloque" de digamos 1 mb, en el que generas el codigo y los "vas consumiendo" cuando se te acaba ese bloque pides otro, sin hacer "mucha gestión" cuando has pedido más bloques que el maximo de memoria que quieres usar para "cache de codigo emitido" coges uno de esos bloques y lo resereteas, invalidas todas las entradas en la tabla de codigo traducido qu ele apunten y puerta, a volver a empezar cno ese bloque
* Lo de La tabla de acceso a los bloques compilados, No se crea en el espacio de direcciones, sino una makina de 32bits necesitaria una tabla muy muy grnade, se crea en el espacio de "memoria física";
Por ejemplo en la psx son 2megas de memoria.
Esto biene a ser que gastas un poco mas de 3 veces la memoria del bicho a emular, la memoria emulada(2mb) + la tabla de aceso al codigo recompilado(2mb hacemos que el codigo este alineadoa 4bytes) + la cache de codigo compilado(aqui toda la memora que quieras hechar).
* Para "optimizar" el tamño de la cache de codigo compilado si vas mal.. se puden genenrar bloque sma spequeños aunque tiene un poco de overhead, porque si estas muy cerca dle final del bloque, empiezas a generar y se te acaba el bloque, te toca pedir otro bloque y "volver a empezar".
Lo bueno de esto es que despues digamos cada n segundos invalidas /borras un bloque de estos de código, con lo que vas eliminado "bloques muertos" de la cache.
Tambien puedes ser "mas listo" y en la informacion de bloques almacenar la cuenta de "recompilaciones de bloques" y cuando un bloque lo has compilado mas de n veces lo mandas a un "bloque qu eno vayas a borrar" asi con siges además que el codigo mas usado este junto..
* Lo que no comprendo de tu dibujo es el cuadrado superior, que pone que se rellena cuando se traduce cada opcode... aqui en eoria todas las cosas se hacen "por bloque".
P.D: la mento las fartas/letras cambiadas pero es muy temprano :P y no quiero repasarlo.
Unai.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.