Diseño/normas del software

Moderadores: largeroliker, Kravenbcn, fidelcastro, cerealkiller, pspCaracas, dark_sasuke, m0skit0, LnD, ka69, zacky06

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5586
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Diseño/normas del software

Mensajepor m0skit0 » 19 Ene 2011, 10:09

Sobre los emuladores en general

Spoiler:
Un "emulador" es, de manera genérica y yendo al tema que nos interesa, un software que corre sobre un tipo de arquitectura hardware X que imita el comportamiento de una arquitectura hardware Y diferente. En nuestro caso más concretamente queremos imitar toda la arquitectura hardware de la PSP en un PC.

Para realizar esto, hay que crear un sistema 100% software que imite un hardware. La imitación debe ser lo más fiel posible, dado que el objetivo final es conseguir que el software que normalmente corre sobre la PSP corra directamente sobre el emulador, esto es, engañarle de manera máxima. Hay que modelizar por software todo el hardware de la PSP, es decir, crear componentes software que imiten de manera fiable y lo más exactamente posible el comportamiento del hardware de la PSP. Resumiendo: hay que crear hardware virtual mediante software.

Uno de los puntos que hay que tener en cuenta es que el hardware realiza operaciones muchísimo más rápido que el software, debido a que éste necesita ya de por sí correr sobre un hardware. Por tanto para emular una máquina por software es necesario que la máquina que emule sea mucho más potente que la máquina a emular. No existen cifras concretas y todo depende realmente de la máquina que se quiere emular y sobre qué máquina.

La mayor dificultad de esto es que la PSP es un sistema cerrado, es decir, no existe prácticamente documentación técnica oficial al respecto.


Estilo del código

H
Spoiler:

Código: Seleccionar todo

/*
- Donde digo "int" digo cualquier tipo
- Uso de TABULACIONES (no espacios) para el sangrado
- Una tabulación por cada sangrado
- Las llaves siempre al principio de línea (no al final aaaargh grgrgrgr)
- Todo lo que va dentro de llaves va sangrado (con excepciones sobre todo en C++)
*/

// Esto SIEMPRE, ahorra innumerables errores compilación de referencias circulares
#ifndef ESTA_CABECERA_H
#define ESTA_CABECERA_H

// Primero las cabeceras estándar
#include <stdio.h>
// Luego librerías extra
#include <peasograficos.h>
// Luego las propias de la aplicación
#include "cabezabolo.h"

// Constantes con mayúsculas!!
#define CONSTANTE_DEFINE
#define OTRA_CONSTANTE

// typedef struct siempre directamente
/*
- Cadenas, sLoquesea
- Estructuras, strLoquesea
- Enteros, iLoqusea
etc...
*/
typedef struct
{
   // Interesante estructura
}strUnTipo;

// Descripción de la clase y su funcionalidad
class cClase: public cClasePadre
{
private:
   // Lo que vaya en cada, tabulado como se debe
protected:
public:
}

#endif


CPP
Spoiler:

Código: Seleccionar todo

// Sólo ésta a ser posible, sólo ésta
#include "cabeceraquecorresponda.h"

// Descripción del cometido del método, de los parámetros de entrada y valor de retorno
int cClase::hace_algo_importante(int parametro1)
{
    // Siempre incializar
    int iDescribeme = 0;

    // Nunca valores literales en el código, siempre usar constantes, salvo valores intrínsecos del lenguaje
   // Siempre con llaves, aunque la sintaxis permita que no se usen
    if (iDescribeme == CONSTANTE_DEFINE)
    {
      // Usa y abusa de los paréntesis (se ve(que programo(en lisp?)))
        while ((iDescribeme > 0) && (iDescribeme < CONSTANTE_DEFINE))
      {
         // Muchas cosas difíciles y complicadas
      }
    }
   else
   {
      // Buah, más difícil aún
   }

   // Todo sangrado en el switch
   switch(iDescribeme)
   {
      case CONSTANTE_DEFINE:
         break;
   }         

   // Un solo return por función!
   return OTRA_CONSTANTE;
}


Diseño de alto nivel

Mi idea básica es crear clases independientes para cada componente hardware de la PSP (se pueden crear subclases para cada componente, eso ya lo vemos). Después crear una clase "placa base" para entendernos, que interconecte todos estos componentes, haciendo la vez de bus hardware.
Imagen

arisma
Habitual
Habitual
Mensajes: 497
Registrado: 18 Sep 2009, 08:41

Re: Diseño/normas del software

Mensajepor arisma » 19 Ene 2011, 11:01

Sería bueno especificar quizás el uso de librerías estándar de C++ como por ejemplo iostream.h
y cuando se quiera usar la librerías estándar(o quizás crear alguna) de C, hacerlo en la forma establecida como anteponiendo la letra c y sin .h.

Es decir,
La librería estandar stdio.h pasa a->

Código: Seleccionar todo

#include <cstdio>


¿Qué te parece?

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5586
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: Diseño/normas del software

Mensajepor m0skit0 » 19 Ene 2011, 11:39

No entiendo realmente qué ventajas aporta o para qué quieres hacer eso. ¿Qué problema hay con usar los nombres tal cual?
Imagen

arisma
Habitual
Habitual
Mensajes: 497
Registrado: 18 Sep 2009, 08:41

Re: Diseño/normas del software

Mensajepor arisma » 19 Ene 2011, 11:53

Es una recomendación.

/** @file cstdio
* This is a Standard C++ Library file. You should @c #include this file
* in your programs, rather than any of the "*.h" implementation files.
*
* This is the C++ version of the Standard C Library header @c stdio.h,
* and its contents are (mostly) the same as that header, but are all
* contained in the namespace @c std (except for names which are defined
* as macros in C).
*/


Y por otro lado, era especificar si vamos a utilizar para las operaciones E/S la libreria estándar de C++ ios y derivados o vamos a usar equivalentes de c.

Preferible en la medida de lo posible hacer las cosas a la manera y con las librerías de C++

Un saludo.

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5586
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: Diseño/normas del software

Mensajepor m0skit0 » 19 Ene 2011, 12:07

arisma escribió:Es una recomendación.

Ok, ya veo que hacen que estén incluídas en el espacio de nombre std. Ok por mí.

arisma escribió:era especificar si vamos a utilizar para las operaciones E/S la libreria estándar de C++ ios y derivados o vamos a usar equivalentes de c.

C++, que para eso hemos elegido C++, aunque por ahora la E/S no nos interesa mucho, primero veamos cómo estructurar y el diseño del conjunto. En un principio la E/S sólo será mera depuración.
Imagen

arisma
Habitual
Habitual
Mensajes: 497
Registrado: 18 Sep 2009, 08:41

Re: Diseño/normas del software

Mensajepor arisma » 19 Ene 2011, 13:34

Sin problemas.

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5586
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: Diseño/normas del software

Mensajepor m0skit0 » 19 Ene 2011, 14:54

Bueno, como ejemplo de mi idea, os dejo esta definición de clase, a ver qué os parece:

Código: Seleccionar todo

/*
 * cAllegrex.h
 *
 *  Created on: Jan 19, 2011
 *      Author: m0skit0
 */

#ifndef CALLEGREX_H_
#define CALLEGREX_H_

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

// Modelado del procesador principal de la PSP
class cAllegrex
{
private:

   /*************/
   /* ATRIBUTOS */
   /*************/
   // Registros genéricos
   tRegistro regGenericos[NUM_REG_GENERICOS];
   // Registros HI y LO
   tRegistro regHi, regLo;
   // Registro PC (contador de programa)
   tRegistro regPc;
   // Registro de instrucción
   tRegistro regRi;

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

   /***********/
   /* MÉTODOS */
   /***********/
   // Recoge la instrucción
   tError recoger(void);
   // Decodifica la instrucción
   tError decodificar(void);
   // Ejecuta la instrucción
   tError ejecutar(void);
   // Almacena la instrucción
   tError almacenar(void);
   // Ejecuta un ciclo de instrucción
   tError ejecutar_ciclo(void);

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

   // Indica al procesador arrancar
   tError arrancar(void);
   // Indica al procesador detener su funcionamiento
   tError parar(void);
   // Indica al procesador una señal de reset
   tError reset(void);
   // Indica al procesador apagarse (¿útil?)
   tError apagar(void);
};

#endif /* CALLEGREX_H_ */

Comentarios, críticas, sugerencias y preguntas las que queráis.
Imagen

arisma
Habitual
Habitual
Mensajes: 497
Registrado: 18 Sep 2009, 08:41

Re: Diseño/normas del software

Mensajepor arisma » 19 Ene 2011, 15:20

Mi sugerencia.

Código: Seleccionar todo

/*
* cAllegrex.h
*
*  Created on: Jan 19, 2011
*      Author: m0skit0
*
* Elementos Privados:
*   ATRIBUTOS.
*   Registros genéricos     : regGenericos[NUM_REG_GENERICOS]
*   Registro HI y LO        : regHi, regLo
*   Registro regPC          : regPc
*   Registro de instrucción : regRi
*   
*   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);
};


Aunque parezca mentira está bien tabulado en gedit, pero bueno al copiarlo.

Me parece más rápido y claro y a buscar la información en el fichero de cabecera(estamos de acuerdo), pero siempre al mismo sitio, que no estar recorriendo la clase entre atributos y métodos para encontrar lo que hace.

Además si es necesario se puede programar algo parecido a javadoc.

Un saludo.

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5586
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: Diseño/normas del software

Mensajepor m0skit0 » 19 Ene 2011, 15:28

Sí, una sugerencia muy buena, me parece excelente.

De todas formas, vayamos pasando el punto del estilo y viendo ya la estructura que queramos que tenga la aplicación

PD: el Javadoc, mejor para Java :lol:

EDITO: veo que falta la descripción de la clase. Aparte, pondría primero el método/atributo y luego la descripción.
Imagen

arisma
Habitual
Habitual
Mensajes: 497
Registrado: 18 Sep 2009, 08:41

Re: Diseño/normas del software

Mensajepor arisma » 19 Ene 2011, 15:47

Cierto. La descripción de la clase falta porque comencé a crear la respuesta aquí mismo, y claro si tabulas te sales de la ventana del texto.

Así que pasé a gedit, y claro se me pasó xD.

EDITO: Tienes razón por coherencia con los métodos, mejor los nombres de los atributos antes de la descripción.

Código: Seleccionar todo

/*
* cAllegrex.h
*
*  Created on: Jan 19, 2011
*      Author: m0skit0
*
**Clase Allegrex      : 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);
};



Volver a “Proyecto Emulador”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 2 invitados