Diseño/normas del software

[m0skit0]

Ok con un par de mínimas correcciones (recuerda que tabuladores y no espacios):

Spoiler:

Código: Seleccionar todo

/*
* cAllegrex.h
*
*  Created on: Jan 19, 2011
*      Author: m0skit0
*
* Clase cAllegrex: Modelado del procesador principal de la PSP
*
* Elementos Privados:
*   ATRIBUTOS.
*   regGenericos[NUM_REG_GENERICOS]      Registros genéricos
*   regHi, regLo                  Registro HI y LO
*   regPc                        Registro regPC
*   regRi                        Registro de instrucción
*
*   METODOS.
*   recoger            Recoge la instrucción. Sin argumentos(o entrada) salida tipo error (o tError)
*   decodificar         Decodifica la instrucción. Sin argumentos(o entrada) salida tipo error (o tError)
*   ejecutar         Ejecuta la instrucción. Sin argumentos(o entrada) salida tipo error (o tError)
*   almacenar         Almacena la instrucción. Sin argumentos(o entrada) salida tipo error (o tError)
*   ejecutar_ciclo      Ejecuta un ciclo de instrucción. Sin argumentos(o entrada) salida tipo error (o tError)
*
* Elementos Publicos:
*   arrancar      Indica al procesador arrancar. Sin argumentos(o entrada) salida tipo error (o tError)
*   parar         Indica al procesador detenerse(pausa). Sin argumentos(o entrada) salida tipo error (o tError)
*   reset         Indica al procesador reiniciarse. Sin argumentos(o entrada) salida tipo error (o tError)
*   apagar         Indica al procesador apagarse. Sin argumentos(o entrada) salida tipo error (o tError). Operaciones antes de *               destructor
*/

#ifndef CALLEGREX_H_
#define CALLEGREX_H_

#include "tipos.h"
#include "cAllegrexInfo.h"

class cAllegrex
{
private:
   tRegistro regGenericos[NUM_REG_GENERICOS];
   tRegistro regHi, regLo;
   tRegistro regPc;
   tRegistro regRi;

   // Coprocesadores también aquí o por separado?

   tError recoger(void);
   tError decodificar(void);
   tError ejecutar(void);
   tError almacenar(void);
   tError ejecutar_ciclo(void);

public:
   // Constructores y destructor
   cAllegrex();
   ~cAllegrex();

   tError arrancar(void);
   tError parar(void);
   tError reset(void);
   tError apagar(void);
};

EDITO: bueno veo que a mí también me sale descolocado aquí, así que mejor adjunto el fichero en sí.
EDITO2: bien, la extensión .h no está permitida así que lo dejo como antes

[Ariath]

Una pregunta, ¿Porqué usar tabuladores y no espacios para los sangrados?

Lo digo por lo siguiente: Antes yo era partidario de usar tabuladores, pero es que luego te fijas y, si te da por mirar rápidamente el código desde una aplicación diferente (por ej: programas en VC++, pero luego quieres ver el código rápido y lo abres con el Notepad mismo), cada una interpreta los tabuladores como le da la gana.

Yo lo que hago ahora, es configurar el Notepad++ para que los tabuladores los interprete como 4 espacios, de esa manera, yo sigo haciendo sangrados cómodamente pulsando una tecla sola, y al mismo tiempo, en lugar de un tabulador se insertan espacios.

Salu2

[m0skit0]

Tabuladores en vez de espacios porque luego cada uno puede configurar el ancho del tabulador como mejor lo vea. Esto no se puede hacer con espacios.

Saludos.

[largeroliker]

Ya que estamos quiero plantear una duda...una vez escrito el código que emula el hardware, el software vendrá en el emulador, o habrá soporte para un FW normal?

[m0skit0]

El objetivo obviamente es conseguir que el propio firmware de la PSP funcione en el emulador. Otra cosa es que haya que hacer un firmware "falso" mientras se trabaja en hacer que funcione el FW oficial (que va a ser cosa de locos, ya os lo adelanto ).

[darkmonster]

es verdad profe, me imagino que al principio se trabajara sobre FW que se adapte al emulador, ya despues veremos el soporte a un FW oficial.

[m0skit0]

Primero a ver si empezamos a hacer algo, eso queda muy lejos aún.

[m0skit0]

Doble posteo porque soy el más guay del lugar:

callegrex.cpp

Spoiler:

Código: Seleccionar todo

cAllegrex::cAllegrex()
{
   int i;
   for(i = 0; i < NUM_REG_GENERICOS; i++)
   {
      regGenericos[i] = VALOR_REG_DEFECTO;
   }

   regHi = VALOR_REG_DEFECTO;
   regLo = VALOR_REG_DEFECTO;
   regPc = VALOR_REG_DEFECTO;
   regRi = VALOR_REG_DEFECTO;
}

cAllegrex::~cAllegrex()
{
   // Nada que hacer
}

tError cAllegrex::ejecutar_ciclo(void)
{
   tError cod_error;

   cod_error = recoger();
   if (cod_error != ERR_OK)
   {
      return cod_error;
   }

   cod_error = decodificar();
   if (cod_error != ERR_OK)
   {
      return cod_error;
   }

   cod_error = ejecutar();
   if (cod_error != ERR_OK)
   {
      return cod_error;
   }

   cod_error = almacenar();
   if (cod_error != ERR_OK)
   {
      return cod_error;
   }

   return cod_error;
}

Sí, he roto la regla del único return por método, pero es que sino el código iba a quedar mucho menos legible.

Una cuestión importante: si tomamos cada componente como una clase unidos todos por una clase "madre" que haga las funciones de placa base, por ejemplo, ¿cómo interconectamos los distintos elementos? Es decir, ¿cómo se comunican entre sí?

Venga, vamos con esto que es el meollo del asunto

[arisma]

Por medio de los metodos, que para eso son públicos.

De todas formas recuerda lo de la herencia de una clase, y la interfaces.
Lo digo porque no sé si te estoy comprendiendo bien.

[m0skit0]

Hombre ya conozco los métodos para comunicar objetos entre sí. Digo con qué lo hacemos, sino cómo y cuál os parece mejor. Que aportéis ideas, vamos

¿C++ tiene interfaces? ¿Eso no era Java? Vaya cacao tengo