Un compilador de ZX Spectrum BASIC

[Bubu]

Estaría guay, pero, ¿qué compilador utilzó p.ej. Dinamic para hacer el BABALIBA o el SAIMAZOOM? Lo digo porque a lo mejor ya está por ahí hecho...

[mcleod_ideafix]

Yo creo que lo realmente complicado son las prioridades en el cálculo y los paréntesis.

No si conoces cómo funcionan los diferentes tipos de gramáticas. Y para ayudarte tienes el Lex y el Yacc. De todas formas, si quieres probar, no tienes más que transformar la expresión que quieras al formato de notación polaca inversa (es de hecho la que usa internamente el calculador de la ROM del Spectrum, y otros muchos procesadores aritméticos). En este tipo de notación, la evaluación de expresiones es sumamente sencilla (por muy compleja que sea la expresión).

[Rafa]

Ya, pero yo me refería a una aplicación que pueda correr en un spectrum normal o en un emulador, traduciendo el basic directamente a assembler.

[sromero]

Estaría guay, pero, ¿qué compilador utilzó p.ej. Dinamic para hacer el BABALIBA o el SAIMAZOOM? Lo digo porque a lo mejor ya está por ahí hecho...

MCODER, pero tiene bastantes limitaciones (de tamaño, no se pueden usar más que 2 vectores, creo, etc).

No es lo mismo que se está planteando aquí: la verdad es que se podría compilar el BASIC tal cual, sin limitaciones como en MCODER... o incluso extender el lenguaje, ya que estamos (me refiero a hacer bibliotecas de funciones llamables desde BASIC, linkables por el compilador junto a nuestro código).

[Bubu]

Por cierto, aquí hay un artículo comparando 3 ó 4 compiladores de BASIC, con gráficas de velocidad y demás. Este artículo se publicó en 1985 en la revista Your Spectrum #21, y pongo este enlace por curiosidad.

[Boriel]

Para Linux, puedes bajarte los fuentes de z88dk y compilarlos en tu target, ¿lo has probado?

Sí, lo probé (de hecho he pertenecí al grupo de desarrolladores de Debian GNU/Linux hace años) pero no lo pude hacer. Me imagino que tendré que toquetear el código fuente. No recuerdo que problema tuve. A veces, simplemente con recompilar no es suficiente.

Sobre BASIC, puedes echarle un vistazo a la documentación del compilador para Spectrum HiSoft BASIC, que por ejemplo implementa el uso de directivas en sentencias REM y funciona muy eficientemente (de 4x a 8x la velocidad del BASIC interpretado, dependiendo de cómo lo hagas).

¿Y dónde la consigo? Supongo que en el W.O.S.

[Boriel]

OK. Todo el mundo dice "que es un proyecto interesante". A ver: ¿propuestas?
Yo creo que lo realmente complicado son las prioridades en el cálculo y los paréntesis. Lo demás, son chorradas.
Yo estoy dispuesto a implicarme. ¿Alguien más?

Precisamente, para mí las chorradas son las evaluaciones de las prioridades de cálculo (ya que eso es lo que hace la herramienta que me construí).
La propuesta no es buscar una forma de analizar expresiones matemáticas, ni demás. Precisamente eso es lo que ya tengo hecho, es decir, ya tengo un prototipo que analiza expresiones matemáticas (con paréntesis, operaciones lógicas, potenciación, etc). Ahora queda la parte de traducir esas instrucciones a ASM o lo que sea, y ver qué método utilizar.

La herramienta que me hice permite definir lenguajes, de manera que ella es la que se encarga de hacer la precedencia de operadores y demás. Como nota de curiosidad, recalco lo que dije en el 1er mensaje, que el BASIC del ZX no evalúa bien la operación de potencias (^). De manera que 2^1^3 da 8, y no 2, que es lo que debería dar. Dado que se busca que sean compatibles, el compilador también tiene en cuenta estas cosas, y las evalúa como lo hace el BASIC del ZX.

Si alguien quiere que me explaye un poco aquí sobre cómo se definen algunas cosillas en el compilador, lo puedo hacer (pero será un rollo friki, y no creo que haya gente interesada).

Expresiones matemáticas
Nombres de variables
Sentencias LET
Sentencias IF THEN
Sentencias GOTO
Sentencias GOSUB

(La definición gramatical de las Expresiones Matemáticas tiene casi más reglas que el resto, por ahora).

De lo leído anteriormente en tu post y los anteriores, he visto ideas interesantes:

* Traducir las instrucciones a llamadas a la ROM, que sería lo más sencillo

* Traducir las instrucciones directamente a ASM (más complicado, pero más eficiente)

* Como el punto anterior, pero usando las llamadas a la ROM para el punto flotante

Para mí el favorito es el punto 3, porque permite combinar velocidad (en caso de enteros) con números flotantes. Es lógico llamar a la ROM para esos cálculos, ya que siempre serán igual de lentos compilados directamente como a través de la ROM, y se ahorra mucho trabajo. Faltaría una rutina de la ROM para pasar de punto flotante a entero de 8, 16 y quizá 32 bits y viceversa (creo que ya existen, si no recuerdo mal).

Las funciones COS, SIN y demás, siempre serán igual de lentas, por lo que se usaría siempre la ROM. Pero otras como bucles con enteros, serían mucho mejor hacerlas directamente en ASM. Es más, otras ideas que he tenido, serían implementar ciertas extensiones como la instrucción MEMCOPY(pos1, pos2, longitud) que copiaría en pos2 los bytes desde pos1, y cosas así. Esta instrucción la veo muy útil.

Tampoco quiero divagar demasiado (por experiencia), que luego no se llega a ninguna parte. Por ahora, lo primero es terminar el análisis sintáctico de TODO el BASIC del ZX, o al menos de la parte interesante. Me falta el PRINT, las funciones trigonométricas y demás. No he encontrado nada de la sintaxis del BASIC del ZX (salvo el manual, evidentemente), así que lo estoy haciendo de cabeza. Tengo una lista de los TOKENS del Basic, pero nada más.

[na_th_an]

En el WOS está el HiSoft, en efecto. No sé si habrán puesto ya la versión en disco para +3 (1.2), y no sé si tienen la documentación de esa última versión en formato Word. Si las necesitas, yo puedo suministrártelas. No hay color con el MCODER. Se traga casi todo el código que se traga la ROM sin rechistar y no hay problemas de memoria apenas porque usa el disco RAM como memoria intermedia para funcionar.

[Boriel]

De lo leído anteriormente en tu post y los anteriores, he visto ideas interesantes:

* Traducir las instrucciones a llamadas a la ROM, que sería lo más sencillo

...

De momento creo que ésta la voy a descartar porque, para que funcione, se necesita de alguna manera que el programa BASIC esté metido en la RAM. El intérprete es típico de aquella época y está programado "a pelo" (Si leo un PRINT, compruebo que lo siguiente sea un AT. Si no es un AT, entonces ... etc). Y mezcla la ejecución de las instrucciones con su interpretación.

Algunas instrucciones, como PLOT y alguna otra, se pueden aprovechar pero otras no. Esto lo he estado deduciendo de mi lectura en "The Complete ZX Spectrum Rom Dissasembly" (libro que nunca pude conseguir en su momento. snif). También me gustaría (más adelante) preguntar algunas cosillas a quienes estén un poco puesto en el tema. Por ejemplo, lo de usar la calculadora de la ROM, está claro. Es una calculadora orientada a pila (stack), y los operadores se meten siguiendo la notación polaca inversa (esto es típico ya que para los compiladores es casi directo convertir una expresión matemática a esta notación y con poca memoria).

¿Donde puedo conseguir alguna rutina en ASM que muestre el cálculo de alguna expresión matemática?

[na_th_an]

Hace algún tiempo vi en los foros del WOS algunos mensajes sobre el tema. ¿Has mirado allí?

[Rafa]

OK. Veo que hay interés por el tema. Seguro que si todos ponemos nuestro granito de arena, seguro que lo vamos a conseguir. La idea es ir leyendo línea a línea del Basic e ir "traduciéndolo" a Assembler para ganar en velocidad, y, estoy casi seguro, en longitud. Yo reservaría un espacio para las variables(numéricas, alfanuméricas y matrices) y un espacio de trabajo.
En el tema de los números, habría que trabajar con ellos en coma flotante, más que nada porque nunca se puede saber si un número dentro del programa, va a ser mayor que 65535 o cuántos decimales va a tener. Se pueden escribir rápidos conversores(más que los de la ROM) en las dos direcciones, en assembler.
En el tema de las variables, habría que guardar un espacio por cada una de ellas, con su nombre, tipo, etc. Para las numéricas, además de su nombre y tipo y cualquier otro dato que se nos ocurra, habría que almacenar su contenido en coma flotante; para las alfanuméricas yo dejaría un espacio de unos 80 bytes, más o menos.
Después yo distinguiría entre sentencias y funciones. Las funciones devuelven un dato y no pueden ir solas. Las sentencias ejecutan tal acción, unas con unos parámetros y otras sin ninguno.
Por ejemplo un 10 PRINT A$
Buscaríamos el contenido, dirección y longitud de A$; lo copiaríamos al espacio de trabajo, pondríamos un bit alto para fin de mensaje e imprimiríamos el mensaje en las coordenadas actuales.

[na_th_an]

Yo creo que si se quiere orientar, por ejemplo, a juegos, se debe permitir definir variables como enteras y como enteras sin signo. HiSoft BASIC permite hacer esto mediante directivas:

1 REM : INT a, b, c
2 REM : INT +d, erudito, fuck

Con esas dos directivas, las variables a, b y c serán enteras y d, erudito y fuck serán enteras sin signo. El resto de las variables serán de punto flotante.

De esta forma eliminamos el problema de saber cómo tratar las variables a la par que proporcionamos un arma muy potente a los desarrolladores. La aritmética entera se puede generar en ASM directamente sin tener que tirar de la calculadora de la ROM, con lo que la subida de velocidad es acojonante.

Sobre el espacio de variables, al ser esto un compilador no es necesario almacenar los nombres de las variables en ningún sitio. Sobre la distinción entre sentencias y funciones, eso es algo que suele hacer el propio generador de procesadores de lenguajes de forma casi trivial, ya que las funciones se definen en la gramática de las expresiones, y las sentencias no.

[Boriel]

Yo creo que si se quiere orientar, por ejemplo, a juegos, se debe permitir definir variables como enteras y como enteras sin signo. HiSoft BASIC permite hacer esto mediante directivas:

1 REM : INT a, b, c
2 REM : INT +d, erudito, fuck

En efecto, na_th_an yo había pensado algo así. Existe otra posibilidad intermedia más: Usar enteros de 8, 16 y 32 bits con y sin signo para operaciones aritméticas básicas (+, -, *, /). Y otra opción es usar punto fijo en contraposición a punto flotante. Es más rápido que el punto flotante, pero, evidentemente, menos adecuado para cálculos matemáticos. Es muy útil cuando se quiere hacer dibujo vectorial (líneas, círculos, etc). Yo lo usé para hacer un display vectorial con un aparato viejísimo (y mucho más lento que el ZX Spectrum) y la aceleración fue brutal.

Sobre el espacio de variables, al ser esto un compilador no es necesario almacenar los nombres de las variables en ningún sitio. Sobre la distinción entre sentencias y funciones, eso es algo que suele hacer el propio generador de procesadores de lenguajes de forma casi trivial, ya que las funciones se definen en la gramática de las expresiones, y las sentencias no.

En efecto. De hecho, mi herramienta es una especie de LEX/Yacc en python para crear compiladores. Ahora le estoy definiendo las reglas del BASIC del ZX y en principio parece que ya distingue muchas sentencias. Me falta:
* Saber cómo traducir esas instrucciones (que es lo que estamos discutiendo aquí)
* Saber cómo compilar el código ASM que generaré (Pasmo?). Estoy bajo Linux, pero dispongo de una máquina Win32 (Virtual)
* Saber cómo ejecutar el código generado. Entiendo que es cargar el .TAP generado en algún emulador.

[Boriel]

Bueno, viendo algunos tutoriales (y la pagina de sromero) me decanto por pasmo que está nativo para Linux x64 y por emulador, el xspect, que admite .tzx (pasmo permite generar directamente .tzx). Esto simplifica muchísimo las cosas, y creo que puedo experimentar directamente con eso. Dios... ¡qué nostalgia!

[Hernan]

por emulador, el xspect, que admite .tzx (pasmo permite generar directamente .tzx).

El xspect tiene un millón de años, yo me decantaria por Fuse:

http://fuse-emulator.sourceforge.net/