DaXHordes.org

Lo que deberías es no usar Windows...

yosoy_bostero escribió:Queria saber si habia alguna tarea a realizar o por donde se estaba encaminando todo

viewtopic.php?f=75&t=5322

yosoy_bostero escribió:Tambien me gustaria preguntarte cual es la idea de la clase cManipuladorsistfich es decir que ficheros pensas manipular y demas.

Cargar/escribir ficheros. Por ejemplo, depuración. Por ahora sólo carga el código de arranque en memoria.

yosoy_bostero escribió:el CPU tenga una coleccion de objetos cMemoria

Demasiados objetos tendría cAllegrex. Además físicamente en la PSP, la CPU no está conectada así.

yosoy_bostero escribió:Al inicializar (construir) cada objeto se "enviaria" ese obejto de cMemoria a la coleccion del cpu. No se que les parece? se que habria que modificar varias cosas, pero evitariamos crear clases de mapeo y ese tipo de cosas.

Evitarías crear clases de mapeo, pero tendrías que poner el mapeo en cAllegrex, con lo cual sería realmente copiar cMapeoDireccionamiento a cAllegrex, haciendo cAllegrex aún más gorda de lo que ya es de por sí. Y sigo sin ver cuál es el problema de tener varias clases. Cuanto más modular el código, mejor. Eso es programación orientada a objetos. Cuantas más clases y más pequeñas, mejor para mantener.

Creo que habia visto lo de las exceptions pero no entiendo mucho asi que me pongo a leer; respecto a lo e la memoria, esta bien son criterios me parece bien, era solo una idea que se me cruzo. te mando un mp por un par de cosas del svn como para no entorpecer el hilo.

Si tu idea no está mal, pero no veo para qué vamos a quitar una clase para meter su contenido en otra. No veo qué ventajas puede aportar realmente salvo hacer de cAllegrex una clase gigante inmantenible.

Acerca de https://code.google.com/p/psp-emu/source/detail?r=35

Teniendo en cuenta que la primera instrucción que se recoge del fichero es digamos:
19 en hexadecimal
25 en decimal
00000000000000000000000000011001 en binario

Sí, he integrado un par de funciones de conversión para tratarlo en binario.
Recojo de este binario los 6 bits significativos (de la derecha) y obviamente en este caso me da el mismo opcode 0x19 ó 25dec.
Si lo miramos en la documentación sería una instrucción MULTU, pero claro, multiplicar 0 por 0 no tiene mucha lógica.

Sé que por medio de la union, el opcode que da en la programación es 9 por lo que sería un JALR, me puedes confirmar cuál es la instrucción correcta.

Lo digo por mirar lo que comentas que no se recoge bien, o estás con ello?

Eso ya está corregido, por favor revisad las revisiones posteriores: http://code.google.com/p/psp-emu/source/detail?r=39

Saludos

Otra tonteria, en la linea de cAllegrex.cpp(Instrucción SRAV)


Creo que debería ser



Debido a que es un desplazamiento de rT a la derecha, cuyo resultado se comprueba y si no es correcto(distinto de cero?) se devuelve indeterminado.

No, en realidad if (regRi[0].tipoR.rD != 0) comprueba que el registro destino no sea el 0 ($zr) ya que éste siempre debe tener el valor 0. Esto hay que comprobarlo en todas las instrucciones que usen registro de destino, ya que dicho valor 0 no se debe sobrescribir (o lo que es lo mismo, $zr siempre debe ser 0). También como segunda medida de seguridad (por si las moscas) habría que poner a 0 dicho registro al principio del ciclo de instrucción (por ejemplo en cAllegrex::recoger()).

En cuanto a la implementación de la instrucción, no sé cuál es SRAV (desplazamiento aritmético a la derecha... ¿V?).

Creo que debe quedar así o no entraría nunca en el if. Ahora comprobaré que no entre siempre

Por otro lado en la página 157/334 del pdf MIPS IV Instruction Set, está la información de SRAV.(Arithmetical Variable)
Y sí, cierto. He leído que se debe comprobar siempre(en el svn) que se ha de comprobar el registro destino, pero en la documentación pone como operación->
if (NotWordValue(GPR[rt])) then UndefinedResult() endif

Por eso me he liado, igual hay que añadir una comprobación para rt > 0

arisma escribió:Creo que debe quedar así o no entraría nunca en el if

Creo que querías decir que entraría siempre que no fuera 0 (si no tiene signo siempre será > 0 a menos que sea 0). Y lo que has hecho ha sido quitar los paréntesis. Ok, me parece buena corrección.

arisma escribió:NotWordValue(GPR[rt])

¿Y sabes qué quiere decir esto?

m0skit0 escribió:

arisma escribió:Creo que debe quedar así o no entraría nunca en el if

Creo que querías decir que entraría siempre que no fuera 0 (si no tiene signo siempre será > 0 a menos que sea 0). Y lo que has hecho ha sido quitar los paréntesis. Ok, me parece buena corrección.

arisma escribió:NotWordValue(GPR[rt])

¿Y sabes qué quiere decir esto?

Uhm no. Quiero decir que si regGenericos[regRi[0].tipoI.rS] > 0 no se envuelve entre paréntesis nunca entra. A no ser que estés comprobando lo que yo comento de NotWordValue.

NotWordValue comprueba si los bits 63..32 son iguales o no al bit 31. Creo que intenta descubrir si la palabra de 64bit contiene una de 32bit correcta.