Diseño/normas del software
Moderadores: Kravenbcn, largeroliker, fidelcastro, cerealkiller, pspCaracas, dark_sasuke, m0skit0, LnD, ka69, zacky06
Re: Diseño/normas del software
Malvado
Gracias.
Gracias.
Re: Diseño/normas del software
Ei! Dame permisos cuando puedas!
Una cosita (casi ni me lo he mirado!) pero habría que emular las caches del procesador. Además el segundo procesador que lleva la PSP (si mal no recuerdo) tiene menos copros que el principal, no lleva VFPU por ejemplo (si lleva FPU) y además tiene un espacio de memoria propio (no recuerdo el rango) para él solito. Lo de la caché es importante creo, más que nada por que al no tener cache snooping ambas cpus pueden trabajar sobre el mismo dato de memoria y realmente no molestarse (demasiado) dado que la cache es CopyBack/WriteAllocate (aunque se puede cambiar la política). Esto afecta directamente a la GU y al tema de mapeo de RAM (direcciones OReadas con 0x80...0).
Si quieres yo le añado las instrucciones de la VFPU, que las he tocado bastante.
Que guachi tios!
Una cosita (casi ni me lo he mirado!) pero habría que emular las caches del procesador. Además el segundo procesador que lleva la PSP (si mal no recuerdo) tiene menos copros que el principal, no lleva VFPU por ejemplo (si lleva FPU) y además tiene un espacio de memoria propio (no recuerdo el rango) para él solito. Lo de la caché es importante creo, más que nada por que al no tener cache snooping ambas cpus pueden trabajar sobre el mismo dato de memoria y realmente no molestarse (demasiado) dado que la cache es CopyBack/WriteAllocate (aunque se puede cambiar la política). Esto afecta directamente a la GU y al tema de mapeo de RAM (direcciones OReadas con 0x80...0).
Si quieres yo le añado las instrucciones de la VFPU, que las he tocado bastante.
Que guachi tios!
Re: Diseño/normas del software
Permisos dados (he borrado tu correo ). Pruébalo a ver si funciona.
Estoy centrado en montar una estructura procesador - memoria que funcione. Una vez esté depurada y funcionando (que el procesador ejecute programas sencillos) de manera estable, creo que será el momento de ampliarla.
De hecho aún no está implementado ningún coprocesador para el Allegrex. Con segundo procesador te refieres al Media Engine, ¿verdad? Llamémosle ME a partir de ahora
Si te fijas en el código que ya hay subido, hay una clase cControladorMemoria, que se puede usar para mapear direcciones a distintos componentes. Así se podría dirigir a memoria principal o a caché según corresponda Ah por cierto, es con 0x40000000 no 0x80000000 (que sino cambiarías a espacio kernel). Lo que viene a ser el bit 30, vamos (0 = caché, 1 = no caché).
Tendrías que crearte el coprocesador enterito Otra opción es hacer que la clase cAllegrex haga dichas operaciones, aunque personalmente creo que ya es bastante gorda (aunque se podría subdividir más aún, con una clase cInstruccion por ejemplo). Una clase cFPU estaría bien para incluir como atributo de los procesadores.
davidgf escribió:Una cosita (casi ni me lo he mirado!) pero habría que emular las caches del procesador.
Estoy centrado en montar una estructura procesador - memoria que funcione. Una vez esté depurada y funcionando (que el procesador ejecute programas sencillos) de manera estable, creo que será el momento de ampliarla.
davidgf escribió:Además el segundo procesador que lleva la PSP (si mal no recuerdo) tiene menos copros que el principal, no lleva VFPU por ejemplo (si lleva FPU) y además tiene un espacio de memoria propio (no recuerdo el rango) para él solito.
De hecho aún no está implementado ningún coprocesador para el Allegrex. Con segundo procesador te refieres al Media Engine, ¿verdad? Llamémosle ME a partir de ahora
davidgf escribió:Lo de la caché es importante creo, más que nada por que al no tener cache snooping ambas cpus pueden trabajar sobre el mismo dato de memoria y realmente no molestarse (demasiado) dado que la cache es CopyBack/WriteAllocate (aunque se puede cambiar la política). Esto afecta directamente a la GU y al tema de mapeo de RAM (direcciones OReadas con 0x80...0).
Si te fijas en el código que ya hay subido, hay una clase cControladorMemoria, que se puede usar para mapear direcciones a distintos componentes. Así se podría dirigir a memoria principal o a caché según corresponda Ah por cierto, es con 0x40000000 no 0x80000000 (que sino cambiarías a espacio kernel). Lo que viene a ser el bit 30, vamos (0 = caché, 1 = no caché).
davidgf escribió:Si quieres yo le añado las instrucciones de la VFPU, que las he tocado bastante.
Tendrías que crearte el coprocesador enterito Otra opción es hacer que la clase cAllegrex haga dichas operaciones, aunque personalmente creo que ya es bastante gorda (aunque se podría subdividir más aún, con una clase cInstruccion por ejemplo). Una clase cFPU estaría bien para incluir como atributo de los procesadores.
Re: Diseño/normas del software
Perfecto todo!
Si añadimos los copros via una clase extra como se ejecutaría? Se discriminan las instrucciones y en función del criterio se mandan a uno u otro CPU? Tienes alguna referencia buena a la codificacion de las instrucciones?
Y una cosita más, en vez de usar operaciones para sacar los registros, opcode, immediate, por qué no usamos unas unions? Dado que es RISC las instrucciones parecen regulares (http://www.student.cs.uwaterloo.ca/~isg ... ps/opcodes) cosa que permite definir un union con 5 o 6 structs en función del tipo y así ahorrarnos mucho código y dejar que GCC haga su trabajo (seguro que lo hace mejor que nostros y todo xD).
Eres rápido eh?
Ah! Sí! Alguna idea de cómo probar el código? Por que sin I/O ta chunga la cosa... En la GB como mínimo la pantalla estaba mapeada en RAM así que correr demos era factible, pero aquí...
Si añadimos los copros via una clase extra como se ejecutaría? Se discriminan las instrucciones y en función del criterio se mandan a uno u otro CPU? Tienes alguna referencia buena a la codificacion de las instrucciones?
Y una cosita más, en vez de usar operaciones para sacar los registros, opcode, immediate, por qué no usamos unas unions? Dado que es RISC las instrucciones parecen regulares (http://www.student.cs.uwaterloo.ca/~isg ... ps/opcodes) cosa que permite definir un union con 5 o 6 structs en función del tipo y así ahorrarnos mucho código y dejar que GCC haga su trabajo (seguro que lo hace mejor que nostros y todo xD).
Eres rápido eh?
Ah! Sí! Alguna idea de cómo probar el código? Por que sin I/O ta chunga la cosa... En la GB como mínimo la pantalla estaba mapeada en RAM así que correr demos era factible, pero aquí...
Re: Diseño/normas del software
davidgf escribió:Si añadimos los copros via una clase extra como se ejecutaría? Se discriminan las instrucciones y en función del criterio se mandan a uno u otro CPU?
Sería una opción.
davidgf escribió:Y una cosita más, en vez de usar operaciones para sacar los registros, opcode, immediate, por qué no usamos unas unions? Dado que es RISC las instrucciones parecen regulares (http://www.student.cs.uwaterloo.ca/~isg ... ps/opcodes) cosa que permite definir un union con 5 o 6 structs en función del tipo y así ahorrarnos mucho código y dejar que GCC haga su trabajo (seguro que lo hace mejor que nostros y todo xD).
Desconocía los unions para serte sincero Yo soy más de ensamblador Veo que nos vienen como anillo al dedo. Pues si quieres modificarlo, adelante Por cierto, creo que sólo tienes que tocar un método de una clase (cAllegrex::extraerInstrTipoA creo recordar).
davidgf escribió:Eres rápido eh?
Sólo en lo que requiere serlo Tengo tiempo libre y me gusta
davidgf escribió:Ah! Sí! Alguna idea de cómo probar el código?
Sí: cout Igualmente se puede crear una pantalla mapeada a memoria si es necesario, pero yo cuando me refiero a
m0skit0 escribió:que el procesador ejecute programas sencillos
quiero decir programas MUY sencillos, véase sumar 2 registros y almacenarlos en memoria. E ir complicando los programas poco a poco e ir depurando.
De hecho yo creo que ya mismo se pueden ir probando los componentes. Se pueden hacer pruebas a cada clase por separado, a ver qué tal funcionan. Se pueden crear clases, por ejemplo en un directorio test, que estén orientadas a probar cada una de las clases, llamando a los métodos con diferentes valores y probando la respuesta de código.
Re: Diseño/normas del software
Bien! Mola! Si mejor unions por que al final queda todo muy guarro (ya no sabes que hace cada desplazamiento, te dejas una máscara, ya sabes...). Luego detalles como el tema de la endianess, que no tenemos en cuenta y que hacen que no sea portable a big endian, pero diria que por ahora nos da igual y no nos complicamos...
Lo de probar es bastante simple (mi experiencia lo dice) con instrucciones "normales" a la que añadas interrupciones ya las liao! xD Además MIPS tiene unos registros especiales que yo personalmente desconozco, supongo que habrá algunos donde cargar el código de excepción y tal.
Y finalmente... tiene MMU? No me he mirado el tema de mapeo de ram de tu código, pero además de mapear RAM de dispositivos hay que ir con cuidado con la paginación si la hay claro!
Con tu permiso mañana o cuando tenga un rato le hecho un vistazo y empiezo a toquetear, si no te parece bien rollback y se acabó e?
Saludos!
Lo de probar es bastante simple (mi experiencia lo dice) con instrucciones "normales" a la que añadas interrupciones ya las liao! xD Además MIPS tiene unos registros especiales que yo personalmente desconozco, supongo que habrá algunos donde cargar el código de excepción y tal.
Y finalmente... tiene MMU? No me he mirado el tema de mapeo de ram de tu código, pero además de mapear RAM de dispositivos hay que ir con cuidado con la paginación si la hay claro!
Con tu permiso mañana o cuando tenga un rato le hecho un vistazo y empiezo a toquetear, si no te parece bien rollback y se acabó e?
Saludos!
Re: Diseño/normas del software
Entonces esperamos a los cambios con uniones?
Al final, lo hacéis vosotros y nosotros de testers
P.D.: undefined reference to `cAllegrex::decodificarInstTipoJ
undefined reference to `cAllegrex::decodificarInstTipoCP
Falta codigo
Al final, lo hacéis vosotros y nosotros de testers
P.D.: undefined reference to `cAllegrex::decodificarInstTipoJ
undefined reference to `cAllegrex::decodificarInstTipoCP
Falta codigo
Re: Diseño/normas del software
davidgf escribió:Si mejor unions por que al final queda todo muy guarro (ya no sabes que hace cada desplazamiento, te dejas una máscara, ya sabes...).
Totalmente de acuerdo.
davidgf escribió:Luego detalles como el tema de la endianess, que no tenemos en cuenta y que hacen que no sea portable a big endian, pero diria que por ahora nos da igual y no nos complicamos...
Buf, quien quiera ejecutarlo en PowerPC que lo haga él mismo
davidgf escribió:Lo de probar es bastante simple (mi experiencia lo dice) con instrucciones "normales" a la que añadas interrupciones ya las liao! xD
Al procesador aún no acepta interrupciones. Eso habría que incorporarlo, pero poco a poco
davidgf escribió: Además MIPS tiene unos registros especiales que yo personalmente desconozco, supongo que habrá algunos donde cargar el código de excepción y tal.
Las excepciones las maneja el cop0. El cop0 se encarga de casi todo el tema de excepciones, depuración, control del sistema en definitiva. Yo he añadido una simulación de pipeline con un vector de 2 registros de instrucción (que tampoco aparecen en los manuales de MIPS, pero en algún sitio hay que cargar la instrucción ).
davidgf escribió:Y finalmente... tiene MMU? No me he mirado el tema de mapeo de ram de tu código, pero además de mapear RAM de dispositivos hay que ir con cuidado con la paginación si la hay claro!
La PSP no tiene MMU ni paginación, así que por ese lado mucho mejor dado que es mucho más sencillo. El mapeo de RAM es para decidir a qué dispositivo enviarle la orden de lectura/escritura que manda el procesador. También se le podría implementar paginación si hiciera falta, pero afortunadamente, no la hace
davidgf escribió:Con tu permiso mañana o cuando tenga un rato le hecho un vistazo y empiezo a toquetear, si no te parece bien rollback y se acabó e?
Claro, así pruebas si te funcionan los permisos de escritura. De todas formas yo no tengo mucho problema en que otra gente toque, ya he trabajado varias veces así. Obvio que hay piques a veces, pero vamos, este es un proyecto entre todos.
arisma escribió:Entonces esperamos a los cambios con uniones?
Realmente es algo muy secundario que sólo afecta a la forma en que se recuperan los distintos campos de una instrucción. No hay que esperar a nada.
arisma escribió:Al final, lo hacéis vosotros y nosotros de testers
Aquí cada uno hace lo que quiere