BlackHole escribió:Hola Hark0,
Ya he leído en tu otro hilo que has abandonado temporalmente el proyecto debido a tus limitaciones de tiempo. En fin, eso nos pasa a todos en algún momento u otro, y al cabo de los meses/años, pues volvemos a retomar temas olvidados. De todas formas, voy a contestar a algunas cuestiones planteadas ahora que la respuesta la tenía fresca, ya que siempre podrás retomar el hilo cuando te vuelvan las ganas.
Esa es la idea, terminar con mis temas pendientes y retomar el asunto... además tengo aparcados un Raspberry (que he estado trasteando un poco) y un Freeduino (también lo he toqueteado un poco -por lo menos para probar que funcionaba-, y he llegado a montar alguna tontería de circuíto en una protoboard)... sin contar con mi juego para iOS, que se me está eternizando...
El por qué se decide crear un procesador con unas especificaciones y no con otras, indudablemente estará determinado por el coste de la investigación y el desarrollo. Hoy en día no solo se rompen la cabeza para miniaturizar los transistores hasta 22 nanómetros, cambiar su disposición espacial en 3 dimensiones, paralelizar la ejecución con estimaciones predictivas del posible código futuro, sino además empaquetar controladores de acceso a memoria y hasta GPUs dentro de la misma pastilla de silicio. Los procesadores modernos tienen tal complejidad que yo hace muchos años que me perdí completamente, conforme iban avanzando los tipos de instrucciones de la familia SSE que llegan incluso ya a hacer complejas operaciones vectoriales en apenas 1 ciclo de reloj.
Comparado con eso, las instrucciones de los primeros 8 bits se nos antojan hoy tan básicas y ridículas, pero tuvieron que inventarse y diseñarse de tal forma que minimizase la circuitería necesaria con el máximo rendimiento. Aún así, tuvieron que optar entre procesadores complejos pero caros (como un Zilog Z80, que es una gozada programarlo debido a su versatilidad) y otros baratos y simples (como un MOS 6502, que resulta más farragoso de programar por los pocos elementos disponibles que lleva, y obliga a una estrategia de código muy diferente). Eligieron Z80 múltiples equipos de oficina con CP/M y nombres extraños, para después llegar a las masas con el TRS-80, Spectrum, MSX y Amstrad. Eligieron 6502 máquinas como Atari 2600, Apple II, Atari 800XL, Commodore 64, BBC Micro y Nintendo NES. No vamos a entrar de nuevo en un hilo Z80 vs 6502, porque ya se hizo en su día. Únicamente decir que las instrucciones simples se ejecutan más rápido pero el código debe ser mayor para calcular lo mismo; es algo que nos volvimos a encontrar años más tarde al deber elegir entre una arquitectura RISC y una CISC.
La gracia de programar un procesador como el DCPU-16 del juego 0x10c, es que es completamente virtual y no tenemos que "crear el metal" para que funcione. Los avances de hoy en día hacen posible que ya algún loco por ahí se haya currado un diseño Verilog de la especificación 1.1, pero que a la vez lo hace incompatible con la especificación 1.7 actual. La evolución de sus especificaciones en breves meses, como ha sucedido, hubiese arruinado cualquier compañía seria de microelectrónica de los años 70, época en la que fueron diseñados los 8-bits. Aún así, de lo básico que es el DCPU-16, contiene las instrucciones mínimas que un procesador debe llevar, y siendo un procesador de 16 bits mínimo, es en muchos aspectos hasta mejor que el 6502 por ser éste uno de 8 bits. Para comunicarse con el mundo exterior, los procesadores suelen usar instrucciones de I/O, o tener I/O mapeada a memoria como hacía el Commodore 64. En el caso del DCPU-16 todo va por interrupciones y los periféricos tienen acceso completo a toda la memoria, pero incluye algo novedoso que no se encuentra en ningún chip de 8 bits: una cola de gestión de interrupciones, donde tú decides si quieres o no atender al siguiente periférico que está en espera.
AHI ESTA! Lo has clavado!
Sobre la DCPU, empecé por mi cuenta en verano a programar un emulador basandome en la versión 1.7. Busqué emuladores que funcionasen correctamente, para poder coger los programas y probarlos en el mío. Me encontré, como ya he dicho en el otro hilo, que había programas que NO funcionaban en todos los emuladores... algo extraño pasaba, así que fué cuando empecé a preguntar en el foro.
A mitad de la programación, y vista la diferencia entre versiones (no descubrí la versión 1.4 hasta hace relativamente poco), es cuando decidí empezar de cero, pero esta vez usando las especificaciones 1.1.
Te puedes imaginar el cacao mental que todo esto me produjo, para empezar pasaba de cosas como SET B,A a SET A,B.... no te quiero ni contar el lío mental entre As y Bs que me he hecho, y eso que tenía impreso toda la información que encontré sobre la DCPU... un lio vamos.
Sobre el tema de la pila, volvemos a lo que tú mismo comentaste: que el procesador es tonto y es responsabilidad del programador no cagarla. En el MOS 6502 resulta que la pila era muy pequeña, estaba gestionada por un registro especial de solo 8 bits y por lo tanto solo podía tener 256 posiciones, que estaban mapeadas entre 0x0100 y 0x01FF inclusive. El Z80 y el DCPU-16 tienen acceso a todo el espacio de direcciones para posicionar la pila donde le venga en gana. Si el programa sobreescribe los valores de la pila, es problema del programador qué hacer con ellos. Justamente los compiladores de lenguajes de alto nivel como C, a la hora de convertir el código a ensamblador, emplean la pila como espacio de intercambio entre los parámetros de entrada y los parámetros de salida de una función, que se resuelven con PUSH y POP en el orden adecuado. También se puede manipular la pila para desviar el curso de la ejecución cuando salimos de una subrutina, y que no vuelva al lugar desde la que fue llamada.
Sobre la pila, registros, etc, creo haber entendido todo... y de hecho funciona de perillas en mis pruebas... (aquí encontré otra cosa rara, había emuladores que apuntaban la pila a 0xFFFF (donde en teoria toca) y había otros que se iniciaban apuntando a 0x0000). Creo que ya he comentado que "teoricamente" entendía el funcionamiento ya que llevo tiempo leyendo sobre todo esto... pero había que ponerlo en práctica...
La parte de las interrupciones tampoco la entendía en su forma de implementarla, pero gracias a la paciencia de @Jepalza y compañeros en sus esplicaciones, al final comprendí su funcionamiento...
Estoy contigo en que un cambio tan "jevy" entre unas especificaciones y otras llevaría a cualquier empresa al traste... de hecho así me sentí yo en algunas ocasiones... en fracaso total por tener que volver a parir todo desde cero...
En resumen, que no es tarea del programador de un emulador el procuparse de esos temas: solo de definir el comportamiento del micro de forma lo más exacta posible. No es por desanimar, pero a estas alturas ya se han hecho más de 20 emuladores de DCPU-16, ensambladores, desensambladores, compiladores de alto nivel, entornos de desarrollo IDE e incluso sistemas operativos con multitarea por tiempo compartido.
Suerte.
Cierto, de hecho en verano descargué todos los emuladores que había, así como sus respectivos sources para echarles un ojo... entendía bien que hacia cada parte del código, pero como puedes imaginar, había que filtrar las "triquiñuelas" de cada programador. De hecho el objetivo de mi emulador era escribirlo lo más sencillo posible, sin trucos, tirando de Basic en su forma más sencilla. Basta decir que no llegué siquiera a montar un Type CPU con sus correspondientes mandangas... todo lo escribí con variales "planas"...
No siento para nada que haya perdido el tiempo, al contrario... he entendido un montón de cosas sobre los ordenadores... siempre hablando desde la perspectiva de procesadores "sencillos".
Espero tener más tiempo en un futuro y seguir con este emulador u otro similar... no será por ganas.
Un saludo!
