¿"Sabe" REALMENTE un programa su PROPIA longitud?

[mcleod_ideafix]

¿Sabe una persona cuánto tiempo va a vivir cuando nace?

Es curioso que la analogía sea aplicable en ambos casos.

Creo que esa es precisamente la analogía humana al problema de la no computabilidad de ciertos algoritmos.

[Hark0]

¿Sabe una persona cuánto tiempo va a vivir cuando nace?

Es curioso que la analogía sea aplicable en ambos casos.

Creo que esa es precisamente la analogía humana al problema de la no computabilidad de ciertos algoritmos.

[robcfg]

Yo creo que la analogía correcta sería si nosotros sabemos nuestra altura o no.

Ni nosotros ni los programas podemos saber cuando vamos a ser destruidos, pero nosotros si sabemos cuanto medimos de alto.

[Hark0]

¿Sabia el Neo en Matrix su proposito?

y del Señor Smith qué....

[Colossus]

Buenas:

Un punto adicional a tener en cuenta es que un mismo fragmento de memoria puede ser código en un momento de la ejecución y datos en otro, o viceversa, ya sea por un error en la programación o intencionadamente. Por poner un ejemplo retro de lo segundo: Steve Turner diseñó las versiones de Spectrum del Avalon y el Dragontorc de tal forma que la rutina para seleccionar joystick o teclado se utiliza únicamente al principio del programa, y esas posiciones de memoria son después aprovechadas para almacenar datos durante el juego.

Un saludo: Colossus

PD: Y sí, a mi también me parece el típico problema indecidible por un algoritmo. Aunque en este caso no se me ocurre cómo aplicarle una demostración de tipo "corte diagonal" como las usadas con el teorema de Gödel o el problema de la detención de Turing.

[Hark0]

Buenas:

Un punto adicional a tener en cuenta es que un mismo fragmento de memoria puede ser código en un momento de la ejecución y datos en otro, o viceversa, ya sea por un error en la programación o intencionadamente. Por poner un ejemplo retro de lo segundo: Steve Turner diseñó las versiones de Spectrum del Avalon y el Dragontorc de tal forma que la rutina para seleccionar joystick o teclado se utiliza únicamente al principio del programa, y esas posiciones de memoria son después aprovechadas para almacenar datos durante el juego.

Un saludo: Colossus

PD: Y sí, a mi también me parece el típico problema indecidible por un algoritmo. Aunque en este caso no se me ocurre cómo aplicarle una demostración de tipo "corte diagonal" como las usadas con el teorema de Gödel o el problema de la detención de Turing.

Nota mental: Buscar info sobre Gödel.

Yo también pensaba en lo mismo.... ¿cuando sabe si es código o datos? Pienso que el responsable es el programador, no el diseñador de la CPU.

[BlackHole]

Para este tipo de cosas están los sistemas operativos, para ubicar y relocalizar el código, e incluso restringir el acceso a la ejecución de zonas marcadas como datos, si hace falta. Desde el Spectrum al Windows 8 hay un mundo, y podemos ver cómo evoluciona el tema debido a las necesidades cada vez más complejas de nuestra sociedad.

Si empezamos por los equipos de 8 bits que solemos conocer, en todos ellos (incluso el extraño Camputers Lynx del que ando estudiando su ROM) el sistema operativo define siempre un área de trabajo para ubicar el BASIC que luego va a ser interpretado. Unos equipos en una posición, otros en otra, pero siempre va a estar calculado el origen, la longitud de cada línea BASIC y un marcador del final de código que puede quizás dar paso a áreas de datos temporales de trabajo (aunque hay equipos con ese área fija e inamovible). Todos estos equipos de 8 bits siempre van a crear un área de "variables del sistema" para dejar apuntados dichos punteros (valga la redundancia) y el programa podría llegar a consultarlos para conocerse a sí mismo. Pero eso es porque ha habido antes un programa maestro -el sistema operativo- que ha definido todo lo anterior.

Porque aunque veamos nuestro código BASIC como un programa, realmente a vistas del procesador no lo es: son meros datos, que serán interpretados para ejecutar de manera ordenada ciertas rutinas de código máquina con ciertos valores de entrada. En estos equipos pequeños monousuario, un programa en código máquina podía tomar el control absoluto del equipo y escribir donde le viniese en gana dentro del espacio de memoria de la RAM, por lo que los conceptos de inicio y final de código dejan de tener sentido... y si no, que se lo digan a los virus polimorfos que autogeneran código.

Cuando en su día se desensamblaba desde el equipo y hoy más cómodamente con los emuladores, nos encontramos siempre con el mismo problema de determinar qué es una instrucción válida. Aquí entra en juego la longitud de palabra de una instrucción en código máquina. Esto ha variado significativamente a lo largo de la evolución de los procesadores. En un Zilog Z80 hay instrucciones de 1, 2, 3 ó 4 bytes que pueden situarse en cualquier dirección de memoria, sea par o impar, por lo que si empezamos a desensamblar en medio de una instrucción multi-byte, no sabemos si es realmente una instrucción o un dato. En otras arquitecturas de procesadores posteriores como el Motorola 68000, la longitud de una instrucción era siempre múltiplo de 2 y debía situarse siempre en direcciones pares, siendo inválidas las impares (eso al menos simplifica las cosas a la hora de desensamblar).

¡Anda que no ha habido protecciones en programas saltando en medio de una instrucción multi-byte, ejecutando (o dejando de ejecutar) código que leído de corrido dentro de un desensamblado más amplio tenía otro significado diferente! O incluso lo contrario: ejecutar algo que "parecían" datos ininteligibles, para después evaluar el estado final de ciertos registros o banderas de la CPU y extraer código cifrado. O código que se iba modificando a sí mismo haciendo XOR con una tabla de valores encadenados y donde era imposible meter breakpoints (ahora con emuladores es una gozada). Y es que los programadores tenían mala leche, pero los piratas éramos peores, hahaha.

Para responder concretamente a la consulta inicial de este hilo, comentar que los programas "monitor" que permitían desensamblar (algunos venían en cartuchos externos tipo Action Replay, o incluso en la propia ROM como el Apple II) lo típico era que una orden "D" mostrase un desensamblado de las suficientes instrucciones para no hacer scroll vertical en la pantalla, a partir de la dirección del contador de programa (PC). También podía admitir un primer parámetro para empezar a desensamblar desde una dirección determinada, o un segundo parámetro para desensamblar un rango completo. Si la salida era por pantalla, normalmente podíamos decidir si se pausaba cuando se llenaban n líneas, o si lo hacía de corrido (porque tal vez lo teníamos redireccionado a una impresora).

[Hark0]

Efectivamente, estoy de acuerdo contigo @Blackhole...

El caso es que en mi afán por programar un emulador, como ya comenté en el otro hilo, quería partir de una CPU MUY básica... no me sirven los Z80 y demases porque traen un montón de instrucciones, registros, etc...

Gracias al Podcast "El Amuleto de Yendor", oí sobre la especificación DCPU-16 del "famoso" Notch... descargué las especificaciones... y me puse ha realizar test... al empezar a encontrar problemas y/o dudas sobre la implementación de un microprocesador, es cuando inicié mis consultas en el otro hilo...

Hoy he abierto este otro hilo porque he llegado a la conclusión que la pregunta NO era SOLO sobre la CPU comentada, sinó que era una duda que nos podemos encontrar más de un programador que empieza en esto de desarrollar un emulador...


Destripar el código "a medias" o "en medio de la RAM", lleva evidentemente un descontrol sobre lo que estamos descompilando... puede ser que entremos en medio de las datas, o quizás estemos leyendo un "medio paso" de una operación, etc... por eso el motivo del hilo... por lo que voy "descubriendo", una CPU en si misma, es una "especie" de máquina de gestionar datos en una memoria, copias aquí, haces una operación de cálculo allá, asignas unos valores en unos registros/memoria, etc...

Vamos, lo que se ha dicho toda la vida, que la máquina en si misma es TONTA... y que el trabajo duro es el del programador... si no "cierras" bien el programa, éste se puede descontrolar y hacer que la CPU haga cosas que no tocan ¿recordáis los RESET de nuestros amados Z80 tras teclear 5000 códigos de las MH? o era error de imprenta, o error al teclear...

Lógicamente un programa también es "tonto", se copia/carga en una determinada posición de memoria y por si mismo se queda ahí, en espera de que el registro PC alcance su posición (o la de alguna función de la "ristra" de bytes introducidos en RAM).... o sea llamado desde otro programa.

Se me ocurren un montón de preguntas más... todas relativas al control/diseño de una CPU.... ¿porque se incluyen unas instrucciones y no otras? ¿Porque solo hay una pila y no varias? ¿que pasa si PC alcanza la posición de la pila? ¿que pasa si el programa intenta sobreescribir la pila? etc etc etc

Tras algunos días de trabajo, y gracias a la inestimable ayuda del personal de este foro, tengo ya un programa que empieza a funcionar... y que gracias a los comentarios en el foro más mis propias experiencias programando (y por la documentación que encuentro) he llegado a algunas conclusiones sobre la CPU que intento emular, y que de TAN BASICA que es, creo que le faltan un montón de las cosas que aquí se han comentado.

Por ejemplo, yo también he estado pensando en AÑADIR UNA ESPECIE DE BIOS y/o usar las técnicas del ZX, añadiendo una zona de variables, asignar las zonas de la RAM que se pueden usar, quizás marcar como en el Spectrum las primeras 16Kb de la RAM a los caracteres de video, variables del sistema, control de dispositivos, etc...

Como he comentado antes, tengo la intención de añadir en una zona de la RAM algo parecido a las "variables del sistema" aunque esto provoque que me salga de las especificaciones de la CPU... me interesa más el conocimiento que el emulador funcione al 100%, no se si me explico...


Y nada más, voy a seguir tecleando código un ratito más. Saludos.

[BlackHole]

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.

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.

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.

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.

[scooter]

Yo creo que un emulador tiene que emular tal cual al procesador y de ese modo colgarse o descolgarse igual que lo haría la máquina original.
Ejemplo tonto, si se hace un salto por registro no sabes a donde vas a saltar si no sabes el contenido del registro y después de eso no sabes si no lo lees que puñetas hay en la dirección a la que se salta.
Un 6502 que no tiene salto por registro si que lo tiene indirecto en página cero que actúa como un registro, si no sabes el contenido de la página 0... idem de lo mismo.

Los procesadores reales no sabían el contenido de la página o o del registro, solo hacían caso y ya está.