In theory, retirement meant I should have more time for hobbies like the Sinclair QL. In practice, as many who have recently retired will tell you, it often doesn’t work like that! People often go “oh, you’ve just retired, you’ll have time to join our committee now!” or something like that. If anything, I’ve ended up busier since retiring than I ever was.

How often will this blog get updated now? Hard to tell. Much of my QL stuff is back out of storage. Now all I need is the time to do something with it all!

One thing I won’t be doing is restoring my old QL website; that was honestly too much work and I’m not getting any younger! Since I closed it down, a few kind people on the QL scene took matters into their own hands and kindly made available a copy of the last version of the site, minus a few things like the QL Forum feed, the site search (which is still possible with something like a site-specific Google site: search), but with most if not all of the downloads. Urs König’s copy of my site is available at https://sinclairql.net/djw/index.html

Note that the ‘djw’ part of the URL is actually slightly wrong. The well-intentioned Urs mistook old QL company names! Mine was actually DJC, not DJW, which was a different and unrelated company. But never mind, the copy of the site is available for those who remain loyal to the good old Sinclair QL and the retro community in general.

If I release any more QL software in the future (and that’s definitely an IF, not a WHEN), I’ll probably do so via this blog and anyone will be free to copy anything I release to other more widely accessed QL websites.

Here are a few useful links to the QL pages I used most in the past – I hope they’re all still there.

The Sinclair QL Forum – Index page

Sinclair QL For Everyone | Facebook (QL discussion group on Facebook)

BSJR QL home (Bob Spelten jr.’s QL website)

Q-emuLator Sinclair QL (Daniele Terdina’s Q-emuLator Sinclair QL emulator)

https://sinclairql.net/djw/index.html (copy of my old QL website)

Sinclair QL Home Computer Development · GitHub

Kilgus.net | Stuff I do (Marcel Kilgus website, includes QPC2 emulator)

Knoware (Per Witte’s excellent QL page, many downloads)

Products for Vintage Home Computers (Rich Mellor – RWAP Software)

Buy & Sell Retro Electronics Home Computers Arcade & Video Games Consoles (SellMyRetro site)

https://www.sinclairql.net (Urs König QL site)

GitHub – SinclairQL/sQLux · GitHub (sQLux emulator from Graeme Gregory)

Thierry Godefroy’s Sinclair QL and QDOS compatible systems support site

Quantum Technology – Specialisti Sinclair QL

Imagen: Prototipo inicial del Sinclair QL elaborado por el diseñador Rick Dickinson.

El lanzamiento del Sinclair QL en 1984 introdujo dos modos de vídeo gestionados por su chip a medida (el ZX8301): 512 × 256 píxeles a 4 colores y 256 × 256 píxeles a 8 colores. Desde una perspectiva estrictamente matemática, estas configuraciones arrojaban relaciones de aspecto de 2:1 y 1:1 respectivamente. Sin embargo, las pantallas analógicas y los televisores comerciales de la época empleaban un formato físico de 4:3.

Esta desconexión geométrica no obedeció a un criterio estético, sino a un estricto compromiso de ingeniería para equilibrar el coste de los componentes, los límites de la tecnología de televisión y las necesidades del software profesional.

Como diseñador, siempre he odiado la relación de aspecto del video en el QL. El ordenador, en sus inicios, iba a ser un portátil con pantalla plana. Sabía que Sinclair trabajó duro para crear una pantalla con esta característica, y suponía que otras marcas habrían podido servirle un producto equivalente para el lanzamiento de su nueva máquina. En ambos casos asumí que la resolución de video del QL estaba condicionada por las especificaciones de los fabricantes de las pantallas, pero me puse a indagar con la IA, y descubrí que las causas de su desproporción pudieron ser otras.

La pantalla plana de Sinclair

La portabilidad del Sinclair QL quedó truncada al cancelarse el desarrollo de su monitor integrado. Inicialmente, el proyecto —bajo el nombre en clave ZX83— iba a incorporar una pantalla plana de 4 pulgadas basada en el tubo CRT plano que Sinclair había desarrollado para su televisión de bolsillo TV80, evolución del prototipo FTV2. A diferencia de los LCD de la época, de contraste deficiente, este tubo desviaba el cañón de electrones de forma lateral para reducir drásticamente la profundidad del aparato. Sin embargo, la viabilidad técnica se interpuso en el camino: la compleja electrónica necesaria para corregir la distorsión de la imagen, junto con el elevado coste de fabricación y su modesta resolución, hacían inviable su producción en masa para un ordenador de negocios. Ante esta falta de rentabilidad comercial, Sir Clive Sinclair ordenó cancelar la TV plana a finales de 1983, obligando a rediseñar el QL sobre la marcha como un equipo de sobremesa convencional con salidas de vídeo estándar.

1. El límite económico de los 32 KB de RAM

En la primera mitad de los años 80, la memoria RAM representaba uno de los costes de fabricación más elevados. Para comercializar el QL a un precio competitivo (399 libras en su lanzamiento), los diseñadores de Sinclair Research limitaron el presupuesto de la memoria asignada a vídeo a 32 KB fijos de un total de 128 KB que traía la máquina. Sólo la pantalla ocupaba una cuarta parte de la RAM disponible, aunque, por suerte, el QL permitía expansión de RAM.

Sinclair fijó este tamaño de la pantalla como un compromiso entre coste de memoria y ancho de banda del bus. La resolución de pantalla, además de ser económicamente ajustada, encajaba de forma exacta en la memoria principal sin requerir circuitería adicional de decodificación:

512 x 256 x 2 bits / 8 bits por byte = 32.768 bytes (exactamente 32 KB)

El modo de 256 x 256 comparte exactamente los mismos 32 KB de memoria, ya que el ZX8301 interpreta los mismos bytes de dos formas distintas según el modo que esté en uso.

Lograr una resolución más cercana a la proporción 4:3 con el mismo ancho de 512 píxeles (por ejemplo, 512 × 384), requeriría 48 KB de RAM. Esto hubiera reducido la RAM disponible para el resto del sistema, entre otras cosas, como veremos.

2. El cuello de botella del bus compartido

El QL contaba con un 68008, una versión de 8 bits del 68000, con registros de 32 bits pero bus de datos de 8 bits, y con el chip de video a medida ZX8301. Además de una salida de video compuesto/UHF para televisores domésticos, el QL incorporaba una salida RGB TTL directa para monitores dedicados.

Para ahorrar piezas, se usó un único bloque de memoria compartida para todo el mapa de memoria del sistema, obligando al procesador y al chip de vídeo a utilizar los mismos cables internos para acceder a ella. Si bien esto era común en los ordenadores de la época, otras máquinas usaban trucos de hardware o chips con funciones gráficas dedicadas. Como el chip de vídeo necesitaba leer constantemente esa memoria compartida para evitar que la imagen del televisor se borrase (refresco de pantalla), acaparaba el bus de memoria, imponiendo tiempos de espera al procesador cada vez que este necesitaba leer o escribir en la RAM compartida, reduciendo su ancho de banda efectivo a algo menos de la mitad, y parte de ese tiempo disponible de la CPU se dedicaba a hacer todo el trabajo con la memoria de pantalla (pintado de caracteres, instrucciones gráficas…).

Para intentar aliviar este atasco, Sinclair utilizó una técnica pionera en ordenadores domésticos: hacer que el chip de vídeo leyera la memoria en ráfagas rápidas de varios datos seguidos, ganando un tiempo muy valioso. Sin embargo, este parche tenía un límite marcado por la imagen de la televisión, que se redibujaba 50 veces por segundo (50 Hz), dando al chip de vídeo una ventana de solo 20 milisegundos para procesar cada imagen:

1.000 milisegundos / 50 veces por segundo = 20 milisegundos

Aumentar la resolución del modo de pantalla o añadir más colores por píxel habría obligado al chip de vídeo a pedir más información dentro de ese mismo lapso de tiempo, tardando más, saturando el bus de nuevo e imponiendo aún más tiempos de espera al procesador.

Esta disputa constante por los buses fue el motivo clave para limitar la pantalla a 32 KB. El ZX8301 no lee los datos de golpe, sino que accede a la RAM mediante pequeñas ráfagas continuas a lo largo de los 20 milisegundos de cada fotograma (acaparando 8 de cada 12 ciclos de reloj). Un mapa de pantalla superior a 32 KB habría exigido un ancho de banda mayor, dejando a la CPU sin los pocos ciclos de acceso que le quedaban para trabajar antes del siguiente refresco de imagen que volvería a frenarlo.

Daños colaterales

La búsqueda obsesiva de la velocidad en las ráfagas no solo fijó el tamaño de la pantalla, sino que condicionó la propia codificación de sus píxeles en memoria. En el modo de 4 colores (negro, rojo, verde y blanco), el ZX8301 lee dos planos de bits alternos (R y G) mediante su acceso en ráfaga de 4 bytes, lo que le permite construir 8 píxeles consecutivos con solo dos accesos a memoria. En el modo de 8 colores, empaqueta 4 bits por píxel en palabras de 16 bits, duplicando la profundidad de color dentro del mismo ancho de banda. Un planteamiento brillante para la época pero con importantes consecuencias en el rendimiento gráfico.

Respecto a esa codificación de color, como curiosidad y ejemplo de las limitaciones del hardware, el QL mostraba 8 colores usando 3 bits de color (R, G, B) + 1 bit de parpadeo (FLASH) en vez de 16 colores en el modo de 256 x 256. El ZX8301 generaba señales de vídeo en formato RGB TTL (0 V para nivel bajo o apagado, 5 V para nivel alto o encendido) por cada canal de color. Debido a esta naturaleza binaria, solo podía manejar encendido/apagado (1 bit) por canal. Los monitores dedicados de la época (como el Vision QL) recibían directamente esta señal RGB digital, por lo que estaban limitados a 8 colores base (negro, azul, rojo, magenta, verde cian amarillo y blanco). A cambio, la nitidez y definición de la imagen eran muy superiores a las de un televisor doméstico. El control de brillo en el monitor cambiaba la intensidad luminosa de los colores mostrados, pero no el color.

El parámetro FLASH es un bit que conmuta el estado de cada píxel (haciéndolo parpadear a intervalos regulares de tiempo). Sinclair prefirió el parpadeo por píxel porque el QL se vendía como máquina de negocios, y en interfaces de texto (procesadores de texto, hojas de cálculo) el parpadeo es más útil que un color extra para resaltar campos, cursores o errores.

3. La barrera de los 50 Hz (PAL) y el entrelazado

El QL fue diseñado para poder utilizarse con los televisores domésticos convencionales mediante el estándar de vídeo analógico PAL. El estándar PAL emite a 50 Hz y consta de 625 líneas en total, pero divididas en dos campos entrelazados (líneas pares e impares) de 312,5 líneas cada uno.

Al descontar las líneas ocultas utilizadas para la sincronización vertical de la pantalla, los ordenadores domésticos solo disponían de una ventana útil de entre 256 y 288 líneas para emitir vídeo en modo progresivo (no entrelazado). Fijar la resolución vertical en 256 líneas garantizaba una señal estable y compatible con cualquier televisor.

Superar las 288 líneas verticales para aproximarse a la geometría 4:3 habría obligado al hardware a emitir en modo entrelazado. En los monitores CRT comunes de la época, el texto de alta densidad parpadeaba de forma severa al entrelazarse, provocando fatiga visual inmediata al usuario.

Overscan horizontal

Otra curiosidad. Debido a que las constantes de tiempo del ZX8301 se diseñaron pensando en el tubo CRT plano del prototipo original y no en un televisor convencional, el modo de alta resolución (Modo 4) sufre un claro overscan horizontal (la imagen se sale por los lados). Esto ocurre porque sus 512 píxeles ocupan 51,2 microsegundos de la línea de vídeo, superando la ventana segura de 48 microsegundos que garantiza el estándar PAL. El resultado era que cualquier televisor común recortaba los bordes, perdiendo entre 24 y 32 píxeles de la imagen repartidos en los laterales —algo que solo se veía completo en monitores especiales como el Vision QL—. Un problema que no se solucionó en la fase de diseño.

4. El requisito de las 80 columnas empresariales

El Sinclair QL se posicionó como un ordenador orientado al mercado ejecutivo y de oficina, incluyendo una suite ofimática desarrollada por PSION. Para trabajar con garantías en tareas de procesamiento de textos u hojas de cálculo, el estándar de la industria exigía visualizar un mínimo de 80 columnas de texto.

Al optar por un ancho de 512 píxeles, el QL podía renderizar fuentes tipográficas con una matriz de 6 píxeles de ancho por carácter, logrando acomodar 85 columnas de texto legibles en la pantalla.

Soluciones alternativas en el mercado de 1984

Frente a este mismo dilema técnico, otros fabricantes optaron por caminos distintos según su público objetivo y rango de precio:

• Apple Macintosh (El camino del monitor dedicado): Lanzado el mismo año que el QL, Apple decidió prescindir por completo de la compatibilidad con televisores. El Macintosh original adoptó una resolución de 512 × 342 píxeles. Para evitar el parpadeo en las 342 líneas, Apple integró un monitor interno de alta frecuencia (22 kHz progresivo en lugar de los 15 kHz de un televisor). Esto permitía píxeles casi cuadrados muy nítidos para oficina, pero disparó el precio de la máquina a 2.495 dólares. Además, al funcionar estrictamente en blanco y negro (1 bit por píxel), el consumo de RAM se contuvo en unos eficientes 21,8 KB.
• IBM PC con tarjeta CGA (El camino del texto estirado): Para resolver las 80 columnas bajo el límite de los televisores, el estándar CGA de IBM recurrió al modo de 640 × 200 píxeles en blanco y negro (16 KB de RAM). Esto generaba una proporción matemática de 3.2:1, lo que en una pantalla física de 4:3 producía píxeles notablemente más planos y estirados que los del Sinclair QL, deformando de forma severa cualquier elemento gráfico circular o cuadrado.

Píxeles anamórficos

Como consecuencia del diseño, el Sinclair QL operaba con píxeles rectangulares (anamórficos), altos y delgados. Era el propio tubo de rayos catódicos de la pantalla el que se encargaba de estirar físicamente el haz de electrones analógico para cubrir la superficie de cristal 4:3. Los desarrolladores de software debían introducir factores de corrección geométrica en sus rutinas de dibujo para evitar que un círculo perfecto en memoria se mostrase en pantalla con forma elíptica.

En el modo de 256 x 256, el píxel rectangular se estiraba horizontalmente. La pantalla tenía menos pixels de ancho, exactamente la mitad, pero a cambio ofrecía 8 colores en vez de 4, y cada pixel ocupaba 4 bits en vez de 2 con la misma cantidad de RAM. Como vimos, uno de esos bits se usaba para activar o desactivar el FLASH o parpadeo de píxel, una característica inusual que operaba directamente en hardware sin consumir ciclos de CPU.

El legado de un diseño condicionado

El Sinclair QL permanece como un claro ejemplo de la informática de transición de mediados de los ochenta, donde cada decisión de diseño gráfico estaba sujeta a una estricta realidad física y económica. La elección de las resoluciones de 512 × 256 y 256 × 256 píxeles demuestra que el verdadero reto de Sinclair Research no fue la falta de visión tecnológica, sino la necesidad de equilibrar los costes de producción con los límites técnicos de los hogares de la época. Aunque el uso de píxeles anamórficos obligó a los programadores a realizar encajes matemáticos para evitar deformaciones en las pantallas 4:3, esta arquitectura permitió ofrecer una máquina con capacidades de visualización empresariales a una fracción del coste de sus competidores directos.

Saber más:

• QL and Beyond, galería de prototipos del QL por Rick Dickinson, su diseñador.
• TV80 FTV1, Video de desmontaje y funcionamiento.
• X_Scale, función SuperBASIC para corrección de geometría.
• Sistema de coordenadas en el QL, la sentencia SCALE.
• Acid Face, un ejemplo de uso de la función para corrección de geometría.
• Volcar imagenes en la pantalla del QL.
• GMOVE, comando para mover bloques de pixels en pantalla.
• Exprimiendo la paleta del QL, con ejemplos.
• Galería de imágenes en modo 4, 512 x 256 a 4 colores.

Voy a confesar una cosa antes de empezar: de adolescente yo miraba mi calculadora con la misma cara con la que otros miraban el póster de un coche deportivo. Mi HP48 no tenía ruedas ni aceleraba de 0 a 100, pero hacía algo que a mí me parecía mucho más increíble: le escribías 3 X SQ (o cosas parecidas, no me hagáis examinarme de RPL treinta años después) y te devolvía 2·X. No un número. Una expresión. Con una letra dentro. La calculadora sabía derivar sin saber cuánto valía X, y eso, para un chaval con más curiosidad que paciencia, era sencillamente magia negra.

La HP48 —y toda la familia de calculadoras RPL de Hewlett-Packard que la precedieron— tenían una forma de trabajar rarísima si venías de una Casio normal: notación polaca inversa, pila en lugar de línea de edición, y un lenguaje interno, RPL («Reverse Polish Lisp», nada menos), que era en el fondo un LISP disfrazado de calculadora científica. La primera de la saga en atreverse con álgebra simbólica fue la HP-28C, allá por 1987: la primera calculadora de bolsillo capaz de resolver ecuaciones y derivar sin convertirlo todo en decimales. La HP48, que llegó en 1990, heredó ese motor y lo hizo legendario entre estudiantes de ingeniería y gente rara como yo, que la miraba de reojo mientras tecleaba BASIC en mi ZX Spectrum, preguntándome cómo demonios hacía aquello.

Han pasado bastantes años —los suficientes como para que ya no me sorprenda tanto ver una máquina hacer cuentas, pero sí los bastantes como para que la pregunta se quedara ahí, aparcada, sin resolver—. Y un día, ya mayor y con menos inocencia, pero exactamente las mismas ganas de curiosear, decidí volver a esa pregunta: ¿cómo lo hacía?

La respuesta, como suele pasar, era menos mágica y más bonita de lo que esperaba: dentro de aquella calculadora vivía un CAS, un Computer Algebra System, un sistema de álgebra computacional. Un programa capaz de manipular expresiones matemáticas como símbolos, no como números: sabe que d/dx (x²) = 2x sin necesidad de que le digas cuánto vale x, igual que sabe simplificar, factorizar o sustituir una variable por otra expresión. No calcula el resultado: calcula la fórmula del resultado.

Los CAS no nacieron con la HP48, ni de lejos. La abuela de todos es Macsyma, un proyecto financiado por DARPA (Defense Advanced Research Projects Agency) que arrancó en el MIT (Massachusetts Institute of Technology) allá por 1968 y que durante años sólo pudo correr en mainframes del tamaño de una habitación. A finales de los 70, en Honolulu, dos programadores (Albert Rich y David Stoutemyer, con su empresa Soft Warehouse) consiguieron meter algo parecido en un ordenador de mesa: se llamó muMATH, y de ahí, en 1988, nacería Derive, uno de los primeros CAS que la gente de a pie pudo tener en su propio PC. Ese linaje —Macsyma, muMATH, Derive, Reduce— es el que, con calculadoras de por medio, acabó llegando a mi HP48 sin que yo lo supiera. Hoy en día todo programa serio de cálculo simbólico —Mathematica, Maple, Maxima (descendiente directo de Macsyma y aún vivo), el Symbolic Toolbox de MATLAB, Octave, SageMath— es, en el fondo, un pariente lejano de aquella misma idea.

Bien, misterio resuelto… o casi. Porque en cuanto entiendes qué es un CAS te asalta la siguiente pregunta, mucho más peligrosa: ¿y cómo se programa uno? Ahí descubres que hay dos caminos. Puedes escribirlo en Pascal, en C, en el lenguaje que quieras, tratando las expresiones como si fueran texto o estructuras de datos genéricas, a base de fuerza bruta y mucho if. O puedes hacerlo en el lenguaje que fue literalmente diseñado para esto: LISP (recuerda lo que significaba la última letra del lenguaje de HP RPL), donde una expresión matemática y una expresión de código son, estructuralmente, la misma cosa: una lista. En LISP, escribir un CAS no es forzar la herramienta contra su naturaleza; es usarla para aquello que la inventaron.

Y ahí fue cuando me dije: «así aprendo LISP». Porque LISP tiene una historia tan larga como entretenida. Lo inventó John McCarthy en 1958, en el MIT, y ni siquiera pretendía que se ejecutara en un ordenador de verdad: era una notación matemática para razonar sobre funciones. Alguien lo implementó a mano sobre un IBM 704 (uno de los estudiantes de John), y ahí quedó fijado para siempre uno de los detalles más entrañablemente absurdos de la informática: las funciones CAR y CDR, que hoy en día significan simplemente «primer elemento» y «resto de la lista», vienen literalmente de los nombres de dos registros de aquella máquina: Contents of Address Register y Contents of Decrement Register. Sesenta y pico años después seguimos usando el nombre de un registro de hardware que ya no existe, y a nadie le extraña. Eso es LISP: un lenguaje que arrastra su propia arqueología con orgullo. En los 80 hasta hubo ordenadores enteros diseñados solo para ejecutar LISP —las célebres «Lisp machines» de Symbolics y compañía— antes de que el enfriamiento de la inteligencia artificial se las llevara por delante. Es, después de Fortran, el lenguaje de programación de alto nivel más antiguo que sigue vivo.

Y ya puestos a aprender LISP, quise hacerlo en el ordenador de la época de mi HP48 que entonces no tenía, pero miraba con curiosidad, comparándolo con mi ZX Spectrum: el Sinclair QL. El mismo que hoy tengo de verdad y con el que disfruto muchísimo.

Así que me puse manos a la obra: necesitaba un intérprete de LISP para construir mi CAS encima. Miré lo que había disponible… y, ya puestos, hice lo que haría cualquier español de a pie, pronunciar la fatídica frase: “Sujétame el cubata, que esto lo hago yo”.

El resultado se llama MyLISP.

MyLISP es un intérprete LISP-1 (sin entrar en tecnicismos: en un LISP-1 las funciones y las variables comparten el mismo «cajón» de nombres —si defines una variable LIST, adiós función LIST—, mientras que en un LISP-2, como Common Lisp, cada cosa tiene su cajón separado. Es más, una cuestión de filosofía que de complejidad, pero define bastante el carácter del lenguaje). Y desde el primer boceto tuve clara una cosa: no quería un LISP de juguete que sólo sirviera para sumar (1 2 3) en una demo. Quería algo usable de verdad, con closures, listas, recursión seria y una gestión de memoria decente — y eso, en un ordenador de aquella época, exige mínimo 640 KB de RAM para que mi niño respire con comodidad.

Antes de ponerme a teclear, tocaba elegir arma. Lo primero que descarté fue SuperBASIC: es estupendo para casi todo en un QL, pero un intérprete LISP necesita construir sus propias estructuras de datos dinámicas (listas enlazadas, celdas, punteros) con un control fino sobre la memoria, y eso es justo lo que SuperBASIC no te da. Así que volví, con nostalgia, al Pascal de mi juventud: quería recuperar aquella programación imperativa de toda la vida, la de los record y punteros, y el QL me ponía sobre la mesa nada menos que tres compiladores distintos para elegir.

El primero, Computer One Pascal, cayó rápido: compilaba a P-code (una máquina virtual dentro de la máquina), lentísimo para un evaluador recursivo tipo Eval/Apply, y encima tenía un bug de traca que colgaba el sistema en cuanto el QL tenía 1 MB de RAM o más —justo la memoria que yo necesitaba aprovechar. El segundo, Metacomco Pascal, tenía detrás una empresa de las buenas (los mismos que hicieron AmigaDOS y el BCPL para el QL), pero su compilador de Pascal era, según todas las notas históricas de la época, un desastre de bugs y rendimiento; el consejo unánime de la comunidad se resumía en dos palabras: «Forget it!». Así que me quedé con el tercero, Prospero Pascal, el que todo el mundo coincide en señalar como el estándar de facto del QL: certificado ISO 7185, código máquina nativo del 68000 (nada de P-code), coma flotante IEEE de precisión simple y doble hecha a mano, y un enlazador capaz de compilar módulos grandes por separado, algo imprescindible en cuanto tu intérprete Lisp empieza a crecer por encima de las dos mil líneas. Tiene un inconveniente casi entrañable —exige un cartucho EPROM pinchado en el puerto de expansión para funcionar, un dongle antipiratería de otra época—, pero a cambio es el único de los tres capaz de sostener sin temblar un motor de recolección de basura mark & sweep y aritmética exacta. Vamos, que, si iba a jugar en serio, tenía que ser con Prospero.

Tras mil peripecias, unos cuantos bugs de los que sacan canas y algún que otro momento de «por qué me habré metido en esto», conseguí un intérprete que creo que está a la altura de enseñarse a la comunidad sin sonrojo.

Con MyLISP funcionando, tocaba la segunda mitad del plan: el CAS. Ahí tuve que aprender de verdad qué son las funciones lambda, qué son las funciones de orden superior, cómo se manipulan listas cuando las listas son el programa, y qué es eso del «azúcar sintáctico» que tanto mencionan los libros de LISP. Y aquí toca un agradecimiento sincero: Claude ha sido un maestro paciente en todo este tramo, explicándome con calma lo que necesitaba entender de los sistemas de álgebra simbólica hasta que las piezas encajaron.

El resultado es un CAS completo, escrito enteramente en MyLISP, corriendo en mi QL. Y funciona de verdad. Si le doy la expresión 3x² de forma que la entienda:

(DEFINE E (MAKEPROD 3 (MAKEPOW 'X 2)))

Y le digo que me la derive respecto a x:

(DERIVA E 'X)              

Me devuelve:

> (* 6 X)

Pero si además le digo que quiero que me lo ponga en notación matemática normal:

(PRINTMAT (DERIVA E 'X))  

Me muestra en pantalla:

> 6x 

Ese 6x es el CAS imprimiendo la derivada en, después de haberla calculado símbolo a símbolo.

Y aun podemos hacer más cosas con este CAS para LISP (observad que he dicho para LISP no para QL…. eso en el próximo articulo) no se queda en derivadas de una variable: también hace derivadas parciales cruzadas, sustituciones, simplificación de árboles de expresiones, orden canónico de términos semejantes… el motor completo que treinta años atrás yo miraba con ojos como platos en la pantallita de mi HP48, ahora vive, hecho a mano, en el ordenador que de niño ni siquiera tenía.

Se cierra el círculo. Con más canas, pero con las mismas ganas.

Podéis acceder a MyLisp en https://github.com/dfernande132/MyLISP

Podéis acceder al CAS en https://github.com/dfernande132/MyLISP-CAS

Prospero Pascal está disponible en la página de Dilwyn: https://sinclairql.net/djw/language/index.html

Daniel Fernandez Santos , Julio 2026

El día 1 de mayo, en Majadas de Tiétar comenzó con la llegada de los asistentes al evento RU Sinclair QL y Compatibles 2026 el viernes: Badaman, Zerover, Naspternds, TitoxUnix, DFSantos, Salvador Merino, Álvaro Alea y un servidor, Miguel Ángel Rojo. Desempaquetamos todas las máquinas que habíamos traído, dejándolas preparadas para la mañana siguiente, cuando comenzaría el esperado cacharreo. Así pudimos empezar a ver todo lo que los compañeros habían llevado al encuentro. La experiencia fue increíble. Mesa por mesa, tanto el hardware clásico como los desarrollos modernos, exponían la historia completa del Sinclair QL, desde sus inicios hasta la actualidad, demostrando que sigue más vivo que nunca.

Lo primero que llamó nuestra atención fue la impresionante mesa que Naspternds había preparado, presidida por varios Sinclair QL acompañados de sus monitores. Entre todas las piezas destacaban una codiciada Aurora y un espectacular CST Thor, adquirido recientemente y equipado con una unidad Gotek.

Durante la jornada se realizó el esperado unboxing de una nueva tarjeta QLion Gold recién llegada de Grecia. El dispositivo demostró ser una maravilla, nos permitimos disfrutar de títulos como Old Tower, acompañado de una excelente calidad de sonido gracias al QLSound, así como del magnífico Batman remake de Joan Gayón.

Otro de los grandes atractivos fue la presencia de una interfaz QL MIDI de Miracle Systems, una pieza extremadamente rara de la que apenas existen unidades en circulación. Gracias a este hardware pudimos reproducir archivos MIDI a través de un equipo japonés especializado, ofreciendo una experiencia sonora excepcional y convirtiéndose en uno de los momentos más memorables del encuentro.

La activa implicación con la plataforma por la clonación y desarrollo de hardware para QL de TitoUnix, le convierten en uno de los miembros más participativos de la escena. Entre sus proyectos más destacados se encuentra la QubIDE clónica, además de diversas ampliaciones de memoria para el sistema, el ensamblaje de la nueva placa base de QL completamente funcional, especialmente teniendo en cuenta la dificultad de localizar determinados componentes originales, aunque todavía es posible encontrar algunos de ellos.

TitoxUnix continúa desarrollando nuevas ideas y proyectos para la plataforma, demostrando que la escena del Sinclair QL sigue muy viva gracias al entusiasmo y dedicación de desarrolladores y aficionados como él, también pudimos ver su impresionante colección de Qls.

Zerover también nos presentó su trabajo en el desarrollo de un teclado para Sinclair QL, además de una gran cantidad de PCB diseñadas por él mismo mediante KiCad.

Su mesa despertó un enorme interés entre los asistentes, no solo por la calidad de sus diseños, sino también por la dedicación y el esfuerzo invertidos en cada uno de los proyectos mostrados.

Otro de los momentos destacados fue el intento de recuperar un microdrive de PSION adquiridos recientemente por un nuevo aficionado al mundo del QL. Se trata de una situación con la que muchos de los que hemos llegado más tarde a esta plataforma nos hemos encontrado: microdrives averiados, cintas deterioradas o membranas quebradas forman parte de la experiencia habitual de restauración y conservación de estos equipos históricos. Durante las pruebas se intentó realizar una copia de seguridad del software, sin embargo, al tratarse de programas de PSION protegidos y en versión española, todo apunta a que únicamente funcionarían correctamente en un QL español, presentando incompatibilidades con sistemas equipados con la ROM inglesa.

Álvaro Alea también nos deleitó con una impresionante colección de placas y desarrollos fabricados por él mismo, demostrando un enorme conocimiento técnico y una gran dedicación al ecosistema del Sinclair QL.

Entre sus proyectos, destacaban varias expansiones RAM -que también están publicadas en su GitHub-, diseñadas para ampliar la memoria del sistema y ofrecer nuevas posibilidades a los usuarios del QL. También pudimos ver clones de la QL Trump Card, una de las expansiones más reconocidas dentro de la plataforma por sus capacidades de memoria y gestión de discos. Entre sus diseños en GitHub se pueden ver cantidad de proyectos: Interfaz de SINCLAIR QL Mini Trump Card, QL 4 floppy addon, Minerva MK2, un clon de la conocida placa ROM pensado para aportar mayor funcionalidad y estabilidad al equipo…

Otro de los desarrollos que despierta gran interés en el mundillo QL es la tarjeta de sonido QLsound, capaz de mejorar notablemente las capacidades de audio del sistema original. Todos estos proyectos reflejan el excelente momento creativo que sigue viviendo la escena del Sinclair QL, donde la comunidad continúa desarrollando nuevo hardware y manteniendo viva una plataforma con más de cuatro décadas de historia a sus espaldas.

Badaman nos trajo varios QLs en los que se estuvieron haciendo varias reparaciones. En uno de ellos se disponía un pieza muy útil, un multirom, basada en la ROM estándar 27C512 instalada en un zócalo. Lleva un conmutador externo con una memoria ROM de 512 KB, lo que permite tener 8 imágenes ROM. El selector de ROM tiene un interruptor de 4 posiciones, 3 de ellas para seleccionar la imagen de la ROM, y el último para activar o no el Toolkit 2. Esta selección se puede hacer sin abrir la máquina, desde la parte de atŕas del QL. Y como almacenamiento interno un QubIDE con ampliación de memoria de José Leandro. Otro equipo para reparar era un QLUB, un aparato para conectar por los puertos de red de QL a un PC con un emulador QL. Badaman es el artífice de la recuperación de material del Club Qlave que recopiló Salvador Merino, posteriormente publicado en la web Sinclair QL Recursos en Castellano, y quien dio origen al grupo de amigos que participamos en este evento.

DFSantos nos deleitó con su QL y un  Spectrum Next, para el cual existe un core de QL muy logrado que pudimos ver allí. Nos presentó su libro “Inteligencia Artificial para el Z80: Si puedes construirlo en 8 bits, realmente lo entiendes” una nueva obra que propone mirar al pasado para entender el futuro. Escrito por José Daniel Fernández Santos, el libro plantea una idea tan simple como fascinante: aprender inteligencia artificial implementando sus conceptos directamente sobre un procesador Z80, el mismo corazón que latía dentro de máquinas tan nostálgicas como el ZX Spectrum, MSX o Amstrad CPC.

La participación de Salvador Merino fue de los momentos destacados del encuentro. Salvador representa la trayectoria dentro de la escena QL española y su papel al frente del Club Español Independiente de Usuarios de Sinclair QL (CEIUQL), conocido como QLave, que mantuvo activo desde Málaga entre 1987 y 1997. El club ayudó a numerosos usuarios en una época en la que conseguir información y software para el QL era especialmente difícil en España. Salvador también compartió sus experiencias en el mundo QL, reafirmando la importancia histórica y técnica que el Sinclair QL sigue teniendo para su comunidad de usuarios. En esta ocasión llevó al evento su caja y teclado profesional SPEM, un kit italiano que se vendía para hacer que el QL fuera más cómodo de usar.

La mesa de Miguel Angel Rojo tenia un completo Sinclair QL equipado con una expansión TDI, ampliación de memoria, controladora Trump. Como sistema de almacenamiento masivo una QIMSI, en la que se utilizan archivos con extensión .WIN, también conserva una unidad de microdrive como mdv2_ y otra unidad MicroPicoDrive que la utiliza como mdv1_, un elemento cargado de nostalgia que sigue siendo imprescindible para los aficionados que nos gusta usar este medio de almacenamiento.

Durante la jornada se realizaron diversas pruebas utilizando QLUB conectado a un portátil que ejecutaba el emulador QemuLator. Gracias al puerto QLnet fue posible transferir archivos entre ambos sistemas mediante un sencillo cable de audio mono, demostrando una vez más la versatilidad y actualidad del ecosistema QL.

Entre otros, también estuvo presente nuestro anfitrión, Carlos Izquierdo, que nos hizo de guía con su gran amabilidad al tremendo recinto del Museo y su impresionante colección de ordenadores de casi todas las décadas. Con él hicimos un viaje por la historia de la computación a través de más de 800 computadoras con las que cuenta la exposición. Seguramente la mayor colección de ordenadores de toda España. Algunos ordenadores fueron encendidos en esa visita. Pudimos ver computadoras de gran escala como supercomputadoras y mainframes, pasando por minicomputadoras, microcomputadoras, PCs, estaciones de trabajo y finalmente una sección con más de 100 videoconsolas.

Se dejaron caer algunos asistentes, que fueron bienvenidos y pudieron experimentar de cerca lo que es un QL en su máximo esplendor. También estuvieron presentes los amigos del museo que nos acompañan en cada evento.

En definitiva, la experiencia fue extraordinariamente positiva y nos deja con el deseo de repetir el próximo año. Una vez más, quedó patente que los entusiastas de la Sinclair QL continuamos manteniendo viva la pasión por esta máquina, demostrando día a día nuestra fidelidad e implicación, pese a las dificultades y al desafortunado devenir que marcó parte de su historia.

Vídeos y fotos del evento

• Visita la galería de fotos aquí.
• Ver el video realizado por el Museo de Historia de la Computación aquí.
• Ver el video elaborado por napsternds aquí.

Modificado el 04/05/2026, cambios en rojo 

Casos especiales: GO TO / GO SUB y variables con espacios

GO TO y GO SUB

Además de poder escribirse en una o dos palabras, he detectado que en un Spectrum +2/+3 (ya que en el «gomas» todo va por tokens y no es posible escribir otra cosa) se puede introducir GOTO20 y el sistema lo separa correctamente como GO TO 20.

Ante esto, he modificado el lexer para que, cuando reciba una sentencia de salto, la trate correctamente en todas sus variantes.

De esta forma, las sentencias GO TO 20, GOTO 20, GO TO20 o GOTO20 generan siempre los mismos dos tokens:

• TK_GOTO
• TK_NUMERO 20

Y lo mismo ocurre con GOSUB, generando correctamente TK_GOSUB y TK_NUMERO.

Nombres de variables con espacios

Realmente no he visto ningún programa que utilice nombres de variables con espacios. Por tanto, he optado por simplificar el caso: si se detectan espacios en un nombre de variable, se eliminan directamente, generando un nombre compacto.

Así, cuando recibo:

LET ANTES O DESPUES = 4

El lexer genera directamente:

• TK_LET
• TK_VARIABLE antesodespues

Procesado en dos fases

Para realizar este cambio, tras buscar distintas alternativas durante la lectura del código y comprobar que el manejo directo se complicaba innecesariamente —especialmente por la coexistencia de palabras reservadas que no admiten espacios y nombres de variables que sí pueden contenerlos—, opté por una solución en dos fases.

El caso de variables con espacios será poco habitual, pero existe, y preferí resolverlo de forma explícita en lugar de cargar al parser con lógica adicional para anticipar combinaciones poco frecuentes. 

 En la primera fase se realiza únicamente el proceso de tokenización. Durante esta etapa, si se detecta que existen nombres de variables separados por espacios, que generan varios tokens consecutivos, al finalizar el proceso del Lexer se pregunta al usuario si desea procesarlos.

En la segunda fase, se reconstruyen esos nombres de variable, uniendo los tokens que originalmente estaban separados por espacios en un único identificador sin ellos, verificando previamente que el nombre resultante no coincida con ninguna palabra reservada del lenguaje.

Por ejemplo, ante una secuencia de tokens como:

TK_LET
TK_VARIABLE antes
TK_VARIABLE o
TK_VARIABLE despues

Se genera:

TK_LET
TK_VARIABLE antesodespues

Ficheros intermedios

Este proceso genera dos ficheros intermedios:

• .TOK, que contiene la tokenización inicial
• .TOS, que contiene los identificadores ya normalizados

De este modo, el parser puede elegir directamente cuál de los dos ficheros debe procesar, sin necesidad de realizar comprobaciones adicionales ni de modificar el mismo fichero en varias pasadas.

Separación de responsabilidades

Esta decisión refuerza una separación clara de responsabilidades dentro del diseño del sistema:

• El lexer se encarga exclusivamente de analizar el texto y generar tokens.
• La normalización de identificadores se realiza como una fase independiente, consciente y explícita.
• El parser puede centrarse únicamente en la estructura sintáctica, sin necesidad de anticipar ni corregir decisiones tomadas en fases anteriores.

Evitar que el parser tenga que buscar patrones por adelantado o reinterpretar secuencias ambiguas simplifica enormemente su implementación y lo hace más robusto y mantenible.

Pensando en el transpilador en SuperBASIC

Esta estrategia resulta especialmente útil de cara al futuro transpilador desarrollado en SuperBASIC, que no destaca precisamente por su facilidad para manejar ficheros. Generar dos ficheros independientes, en lugar de leer y modificar uno sobre la marcha, simplifica mucho la implementación y reduce el riesgo de errores.

En definitiva, se trata de priorizar una solución sencilla, explícita y robusta: cuanta menos lógica compleja se introduzca en las fases críticas del proceso, más fácil será mantener y evolucionar el sistema a largo plazo.

Índice de entradas del conversor

Cambios el 01/05/26 marcados en rojo 

Mejorando el transpilador: IR estructurado y parser avanzado

En el desarrollo de un compilador no solo importa que el código “funcione”, sino que cada fase esté bien delimitada y tenga responsabilidades claras. En este artículo repasamos una mejora importante en el proyecto actual del transpilador de ZX BASIC: una revisión de la arquitectura general, la resolución de algunos retos léxicos concretos del lenguaje y, sobre todo, un cambio estructural en el parser que impacta directamente en el análisis semántico y en la generación de código.

Índice

• 1. Arquitectura del compilador
• 2. Casos especiales del ZX BASIC
• 3. IR estructurado, PRINT y polaco inverso

1. Arquitectura del compilador: lexer, parser, semántico y generador

Los compiladores suelen dividirse en cuatro fases clásicas, cada una con un papel bien definido. Esta separación es fundamental para mantener el código extensible, depurable y preparado para futuros backends.

Lexer (analizador léxico)

El lexer es la primera fase del proceso. Su tarea es transformar el texto fuente en una secuencia de tokens: identificadores, números, palabras clave, operadores y signos de puntuación. En esta fase se ignoran detalles como espacios irrelevantes o comentarios y se normaliza el formato.

Una decisión clave del diseño es que el lexer produzca tokens semánticamente completos. Esto evita que el parser tenga que reinterpretar combinaciones de palabras o resolver ambigüedades que no le corresponden.

El lexer solo conoce los elementos básicos del lenguaje: separadores, delimitadores y palabras reservadas. Un tema importante que se resuelve aquí es el de los comentarios, que pueden variar desde el simple REM del BASIC clásico hasta los de estilo C de una línea // o de várias líneas /* */.

Habitualmente los comentarios se eliminan en esta fase, pero en nuestro caso se conservan ya que el objetivo es un transpilador en el que puedan mantenerse o descartarse a elección.

Parser (analizador sintáctico)

El parser recibe la secuencia de tokens y la interpreta según la gramática del lenguaje. El parser trabaja por sentencias completas de una o varias líneas, lo que en nuestro caso se simplifica ya que el BASIC se estructura por líneas, por lo que nuestro parser trabaja línea por línea, detectando sentencias, expresiones y separadores como : o el fin de línea.

El resultado del parser debería ser un árbol sintáctico, pero he optado por una forma simplificada: una representación intermedia (IR) estructurada, que conserva la forma del programa pero es más fácil de analizar y transformar.

Inicialmente el parser emitía sentencias “ajustadas” como texto, lo que obligaba al semántico y al generador a volver a analizarlas. Esto se ha corregido parcialemnte emitiendo ya tokens y estructuras explícitas desde el parser.

El parser detecta errores estructurales (por ejemplo, un LET sin un =), pero no valida aún el significado profundo del programa.

Semántico

El análisis semántico valida el significado del programa: existencia de variables, tipos, uso correcto de arrays, coherencia de expresiones y saltos válidos. Aquí ya no importa cómo estaba escrito el código original, sino qué representa.

Esta fase se beneficia enormemente de que el parser proporcione estructuras claras y no cadenas ambiguas.

Generador de código

Por último, el generador traduce la IR validada a un backend concreto, como SuperBASIC o ensamblador 68000. Al trabajar sobre estructuras bien definidas, puede centrarse únicamente en cómo emitir el código.

2. Resolviendo casos especiales: GO TO / GO SUB y variables con espacios

He cambiado ligeramente esto, ver la entrada Cambio de idea en los temas especiales, la idea es la misma solo cambia la resolución.

GO TO y GO SUB

El ZX BASIC tiene particularidades históricas heredadas del ZX80/81, máquinas con 1Kb de memoria, por lo que ahorrar espacio era fundamental. En el Spectrum un tema llamativos es el uso de sentencias formadas por dos palabras:

• GO TO en lugar de GOTO
• GO SUB en lugar de GOSUB

Esto se produce porque heradado de los ZX80/81, internamente el Spectrum no almacena cadenas de texto para las palabras reservadas, sino códigos dentro del propio juego de caracteres. Por ejemplo, al ejecutar PRINT CHR$(236) aparece en pantalla GO TO, lo que hace que internamente sea un solo código, pero se presente en pantalla como 5 caracteres.

Aunque en los listados pueda verse separado, semánticamente siempre es una única sentencia. Para tratarlo correctamente y aceptar las dos formas de escribir la sentencia, el lexer emite tokens separados para TK_GOTO, TK_GOSUB que ya se tratan sin problemas, y además para TK_GO, TK_TO, TK_SUB, y he optado por resolver este segundo caso en el parser por comodidad:

• Si aparecen TK_GOTO o TK_GOSUB, se aceptan directamente
• Si aparece TK_GO, se mira el token siguiente
• Si es TK_TO, se genera un único token TK_GOTO uniendo ambos tokens.
• Si es TK_SUB, se genera TK_GOSUB uniendo ambos tokens.
• Cualquier otro caso es un error.

Así, el resto del parser y el semántico trabajan siempre con sentencias completas sin ambiguedades, y aunque parezca un poco inconsistente usar el mismo token para dos cosas, de esta manera tampoco hay conflictos con el TO usando en el bucle FOR.

Nombres de variables con espacios

Otra particularidad del ZX Spectrum es que los nombres de las variables pueden contener espacios, los cuales son ignorados por el intérprete. Así, A B es equivalente a AB. Este comportamiento proviene del modo en que el analizador de sentencias elimina los espacios considerados no significativos durante el análisis. No obstante, en mi opinión esto no responde a una decisión de diseño consciente, sino más bien a un bug del intérprete que no contempla correctamente este caso.

No he encontrado documentación oficial que lo acredite explícitamente como un bug, aunque no soy el único que lo interpreta así, como puede verse en este comentario técnico: los nombres de variables pueden contener espacios .

Como curiosidad histórica, en el lenguaje FORTRAN los espacios tampoco son significativos en ningún punto de la sentencia. Esto daba lugar a ambigüedades bien conocidas, como el clásico ejemplo:

    DO10I=1,10

donde el compilador no puede distinguir, hasta encontrar la coma, si se trata de una asignación:

    DO10I = 1

o de un bucle:

    DO 10 I = 1,10

En ZX BASIC este comportamiento permite construcciones como esta que funcionan correctamente y muestran un 4 en pantalla:

    LET A B=4 : PRINT AB

Para evitar estas ambigüedades en el transpilador, el lexer separa por espacios y produce varios identificadores en este caso, uno para A y otro para B, luego en el parser se detecta que existen varios  identificadores consecutivos y se unen en uno solo, sustituyendo los espacios por un guion bajo (_) y generando la variable A_B. Como este carácter no pertenece al juego de caracteres del Spectrum, no puede entrar en conflicto con el código original. De este modo, el parser emite internamente:

LET A_B=4 : PRINT AB

El semántico considera equivalentes A_B y AB, y finalmente el generador emite el nombre correcto para el backend, produciendo:

    LET AB=4 : PRINT AB

sin ambigüedades y totalmente compatible con SuperBASIC.

3. IR estructurado, PRINT dividido y polaco inverso

No me resultaba satisfactorio que el parser enviara información que luego el semántico debía volver a analizar. Por ello he cambiado la representación de expresiones y PRINT, acercándola más a un árbol real, pero usando una forma lineal conocida como montón (heap), que corresponde al recorrido en postorden del árbol.

División estructurada del PRINT

En versiones anteriores del transpilador, el PRINT se generaba como texto concatenado, lo que obligaba al semántico y al generador a reinterpretar de nuevo su contenido. Esto resultaba frágil y poco extensible. Para evitarlo, ahora el parser divide cada PRINT complejo en una secuencia de elementos estructurados.

Cada elemento del PRINT se representa como una unidad independiente que contiene:

• El tipo del elemento (cadena, variable, AT, TAB, INK, etc.)
• El separador asociado (;, , o ninguno)
• El valor completo del elemento

Por ejemplo, la siguiente línea en ZX BASIC:

    PRINT AT 3,4,"Nombre: ";N$;TAB(20);INK 3;"Edad: ";EDAD

Es descompuesta por el parser en una serie de instrucciones PRINT independientes, cada una representando un único elemento lógico:

    PRINT <AT>        <3,4>        <,>
    PRINT <CADENA>    <"Nombre: "> <;>
    PRINT <VARIABLE>  <N$>         <;>
    PRINT <TAB>       <(20)>       <;>
    PRINT <INK>       <3>          <;>
    PRINT <CADENA>    <"Edad: ">   <;>
    PRINT <VARIABLE>  <EDAD>       <none>

Esta representación intermedia permite que cada fase posterior trate los elementos de forma adecuada, sin necesidad de volver a analizar texto.Durante la generación de código para SuperBASIC, estas instrucciones se traducen en:

    AT 3,4            
    PRINT ,           
    PRINT N$;
    PRINT TO 20;      
    INK 3             
    PRINT "Edad: ";
    PRINT EDAD

Hay varios cambios en SuperBASIC que obligan a hacerlo de esta manera:

• AT ya no forma parte del PRINT, se debe lanzar por separado
• Los modificadores gráficos (INK, PAPER, etc.) tampoco se pueden usar ya dentro de un PRINT 
• TAB cambia el nombre por TO, y no se deben usar paréntesis en su parámetro (en el Spectrum se puede usar con o sin paréntesis) 
• Los separadores se tratan siempre correctamente. La segunda línea generada parece estraña, pero reemplaza a la coma tras el AT en la sentencia original, que ya no forma parte del PRINT. Pero la coma es necesario incluirla para mantener lo que intenta presentar en pantalla el programa original. Como usar una coma tras un AT o tras un TAB no tiene sentido, el parser emite un warning de aviso únicamente.

El resultado es un código más limpio, correcto y fácil de generar, sin alterar para nada el código original, solo adaptado a la forma de trabajar del SuperBASIC.

Expresiones en polaco inverso (RPN), árbol y montón

Hasta ahora, el parser analizaba las expresiones, pero luego las enviaba prácticamente en bruto al semántico, que debía volver a analizarlas. Esto implicaba repetir trabajo y hacía el sistema más frágil. Para evitarlo, el parser genera ahora una representación estructurada de las expresiones basada en el recorrido del árbol sintáctico.

Internamente, toda expresión puede representarse como un árbol, donde los nodos son operadores y las hojas son operandos (variables, literales, constantes, etc.). Por ejemplo, la expresión:

A + B * C

se puede representar mediante el siguiente árbol:

    +
   / \
  A   *
     / \
    B   C

En lugar de almacenar explícitamente el árbol, el parser lo recorre en postorden (primero los hijos, luego el nodo) y guarda el resultado en una estructura lineal denominada montón (heap). Esta representación corresponde a lo que se conoce como notación polaca inversa o RPN (Reverse Polish Notation):

A B C * +

El montón es, por tanto, un árbol almacenado de forma lineal: conserva toda la información estructural, pero sin necesidad de punteros ni referencias explícitas, lo que facilita enormemente su almacenamiento y recorrido.

La evaluación de una expresión en RPN se realiza mediante un autómata de pila, siguiendo una regla muy simple: cuando se lee un operando se apila, y cuando se lee un operador se desapilan los dos elementos superiores, se aplica la operación y se vuelve a apilar el resultado.

Siguiendo el ejemplo anterior, la evaluación de A B C * + se realiza así:

Lee A  -> se apila A                (A)
Lee B  -> se apila B                (B, A)
Lee C  -> se apila C                (C, B, A)
Lee *  -> C * B, se apila resultado (C*B, A)
Lee +  -> (C*B) + A                 (resultado final)

La gran ventaja de este enfoque es que ya no son necesarios paréntesis ni reglas implícitas de precedencia durante la evaluación: el orden de las operaciones está completamente determinado por la posición de los elementos en el montón. La única responsabilidad del parser es generar correctamente el árbol y recorrerlo respetando la prioridad de los operadores.

Gracias a esta representación, el semántico puede validar fácilmente las expresiones (tipos, operaciones permitidas, número de operandos), y el generador puede emitir código eficiente sin necesidad de reinterpretar la expresión original.

Impacto en el semántico y el generador

• El semántico trabaja directamente con estructuras, sin reinterpretar texto.
• El generador emite código más limpio y eficiente.

Este enfoque hace que el transpilador sea más robusto, más extensible y más preparado para múltiples backends.

Este tipo de decisiones estructurales, aunque no siempre visibles desde fuera, son las que marcan la diferencia entre un traductor funcional y un compilador sólido y mantenible (y sí, también sirven de consuelo cuando uno se da cuenta de que ha tenido que volver a  rehacer parte del camino por no preveerlo desde el inicio).

Este proceso está muy desordenado, ya que he ido alante y atrás todo el rato cambiando el planteamiento de las cosas varias veces, además de ir añadiendo mejoras y simplificando temas, pero es lo que hay cuando no haces un estudio completo antes de empezar, ir programando sobre la marcha tiene estos temas.

01. ZB2SB. Conversor de Basic de los ZX al Super Basic del QL (Reinicio)
02. Definir el Lenguaje de origen
03. DIRECTOR DEL PROCESO
04. Estructuras de datos
05. LEXER. ANALIZADOR LÉXICO. Estructuras de datos para el Lexer
06. LEXER. ANALIZADOR LÉXICO. Planteamiento
07. Un nuevo comienzo
08. PARSER. Analizador semántico
09. GENERADOR de código en SuperBASIC 
10. Otra vuelta atrás (y van...)
11. Mas mejoras (los cambios no acaban nunca)
12. Cambio de idea en los temas especiales

Primer intento de desarrollo, fallido, pero quizá te interese ver alguna cosa

01. Introducción
02. Analizador Léxico primera parte: Lectura de líneas 
03. Analizador Léxico segunda parte: Extractor de Tokens

Índice de entradas del conversor

Otra vuelta atrás: IR con tokens

Como ha ocurrido otras veces durante el desarrollo del proyecto, cada vez que empiezo a generar código válido aparece un problema no contemplado y me obliga a retroceder un paso más. En este caso ha sido un tema de espacios excesivos.

No sirve de nada generar código como:

LET A ( C + D ) = G ( 3 * 4 )

en lugar de:

LET A(C+D)=G(3*4)

En una máquina con recursos limitados, cada carácter cuenta. Podría parecer sencillo “eliminar espacios”, pero eso llevaría a errores como convertir:

IF A AND B THEN C = 3

en algo no válido como:

IF AANDB THEN C=3

Para usar únicamente los espacios imprescindibles es necesario identificar correctamente palabras reservadas, variables, operadores y separadores. Eso implica que los tokens deben estar disponibles en la fase correcta: el generador. Por simplificar el IR inicial, no los incluí… y ahora solo quedaban dos opciones: volver a tokenizar en el generador (lo cual es absurdo) o generar el IR conservando los tokens.

En esta entrada documento otro de los cambios arquitectónicos realizados en ZX2SB. Tras decidir no usar un AST completo por su complejidad, pasé a un IR lineal simple. Ahora el paso lógico es evolucionar hacia un IR lineal basado en tokens semánticos.

Aunque puede parecer otra “vuelta atrás”, en realidad es una decisión motivada por la naturaleza del lenguaje BASIC, por la experiencia práctica adquirida durante el desarrollo del transpilador y, sobre todo, por la necesidad de generar código SuperBASIC limpio, editable y sin reconstrucciones artificiales.

Índice

• ¿Qué es el IR en ZX2SB?
• El problema del AST completo en BASIC
• La decisión: IR lineal con tokens semánticos
• Tokens canónicos y eliminación de ambigüedad
• Espacios, formato y generación correcta
• Ventajas prácticas del nuevo IR
• Conclusión

¿Qué es el IR en ZX2SB?

En lenguajes más complejos y de estructura libre como C o Pascal, el AST es imprescindible. BASIC, en cambio, es un lenguaje más sencillo y organizado por líneas, lo que permite simplificar su representación interna.

En ZX2SB, el IR (Intermediate Representation) es la forma intermedia generada tras el análisis sintáctico y semántico del ZX BASIC original, y sirve como base para:

• Renumeración de líneas
• Reescritura de saltos
• Optimización estructural
• Generación del código SuperBASIC final

El IR no es solo texto, pero tampoco es ejecutable: describe la intención del programa sin la complejidad de manejar un árbol completo, y además se puede guardar fácilmente como texto lineal.

El problema del AST completo en BASIC

Un AST clásico es ideal para lenguajes donde la semántica está profundamente anidada y la estructura es jerárquica.

BASIC, y en particular ZX BASIC, tiene características distintas:

• Sentencias lineales
• Control de flujo basado en números de línea
• Expresiones relativamente simples
• Poca recursividad sintáctica

Mantener un AST completo obligaba a aplanar el árbol para generar código, volver a decidir espaciado y operadores, y en muchos casos reinferir información que ya se conocía.

“¿Por qué tengo que volver a tokenizar o reinterpretar lo que yo mismo ya había parseado?”

Durante un tiempo decidí continuar con el IR simple porque era “suficiente”, pero al final la realidad es que los errores no se mantienen: se refactorizan.

La decisión: IR lineal con tokens semánticos

La solución adoptada es intermedia entre un AST completo y un IR puramente textual:

Un IR lineal, basado en tokens tipados y semánticamente anotados.

Cada sentencia BASIC se representa mediante:

• Un tipo de sentencia (IF, LET, FOR, PRINT…)
• Campos estructurales explícitos
• Expresiones como listas ordenadas de tokens

No existen árboles internos complejos ni se guardan nombres textuales de sentencias, sino identificadores internos, lo que simplifica enormemente el trabajo posterior.

Tokens canónicos y eliminación de ambigüedad

Uno de los problemas recurrentes era usar nombres distintos para el mismo token en distintos módulos. Un simple Par_Ape frente a ParenIzq puede provocar horas de depuración absurda.

La solución fue eliminar completamente:

• Nombres textuales de tokens
• Strings mágicos entre módulos
• Dependencias implícitas entre fases

En su lugar se introdujeron TokenID canónicos:

• Identificadores numéricos estables
• Definidos en un único enum
• Usados por lexer, parser, IR y generador

Ahora todo el sistema habla exactamente el mismo idioma.

Espacios, formato y generación correcta

El nuevo IR resolvió definitivamente el problema del espaciado. La idea clave es simple:

“No eliminamos espacios. Decidimos cuándo ponerlos.”

Al conservar operadores, paréntesis y separadores como tokens reales, el generador puede emitir código compacto o legible, sin ambigüedades y sin depender de parches, y evitando usar expresiones regulares, no se soportan en SuperBASIC y el objetivo final es portar el código de ZX2SB a SuperBASIC.

Ventajas prácticas del nuevo IR

• No se recompone información ya conocida
• No se retokeniza texto generado
• El IR es imprimible y depurable
• El código SuperBASIC generado es editable
• El sistema escala sin hackear fases anteriores

“El diseño deja de luchar contra el lenguaje y empieza a trabajar con él.”

Frase muy bonita que solo quiere decir que me auto animo a seguir adelante, a pesar de las peleas que tengo contínuamente con el código, es mi primer "compilado" completo y se nota.

Conclusión

Abandonar un AST completo no significa perder rigor si el IR está bien diseñado. En ZX2SB ha supuesto mayor coherencia, menos fases ficticias y un generador más simple y fiable.

Como suele ocurrir en ingeniería de lenguajes, la solución elegante no fue añadir más estructura, sino conservar solo la estructura que importa.

ZX2SB Project (algún día será un proyecto serio; de momento es una fuente constante de problemas… y un entretenimiento mental bastante divertido)

https://www.theqlforum.com/viewtopic.php?p=71508#p71508

Estará disponible en tres versiones, de las que hará públicos los archivos para que cualquiera pueda montársela:

1) Expansion port Pi Zero 2
2) Expansion port CM4
3) Internal CM4

Según los bechmarks que ha publicado, ha conseguido alcanzar un redimiento de 40x el QL estándar.

Estaremos atentos a la disponibilidad para poder probarla y comentar nuestras impresiones.

Una gran noticia para el QL!!!

El generador en ZX2SB: diseño, decisiones y límites conscientes

En el proyecto ZX2SB, el generador es el componente encargado de transformar la representación intermedia de un programa ZX BASIC en código SuperBASIC para el Sinclair QL. Aunque pueda parecer que su función consiste únicamente en “emitir líneas de código”, en la práctica es uno de los elementos más importantes y delicados de todo el sistema.

Este artículo describe qué hace realmente el generador, cómo está diseñado, qué problemas resuelve y, sobre todo, qué problemas decide conscientemente no resolver. Esa última decisión resulta clave para entender por qué ZX2SB va más allá de un simple transpilador mecánico .

Índice

• 1. ¿Qué es el generador?
• 2. Generación estructurada de código
• 3. Numeración, control del flujo y bloques
• 4. Instrucciones no portables
• 5. Convención FN_ y desacoplo
• 6. Inicialización e inclusión de funciones FN_
• 7. Qué se obtiene al final
• 8. El siguiente paso inmediato
• 9. Más allá del generador

1. ¿Qué es el generador?

Conviene recordar una distinción fundamental: un compilador genera un ejecutable, mientras que un transpilador genera código fuente en otro lenguaje, que puede ejecutarse directamente o servir como entrada para otro compilador.

En ZX2SB, el generador actúa como la última fase del transpilador. Recibe una representación intermedia (IR) del programa ZX BASIC, ya validada por el lexer, el parser y el análisis semántico, y produce un programa SuperBASIC funcional y estructurado.

Desde el principio se descartó una traducción línea a línea. El generador trabaja con conocimiento de contexto: estructura, bloques, flujo de control y decisiones previas. No se limita a copiar instrucciones; las reformula. 

NOTA: 

En esta fase, el objetivo se cumple tal cual, en fases posteriores se puede ampliar para incluir un entorno de simulación del ZXBasic y que el programa se comporte como en un Spectrum en Basic.

2. Generación estructurada de código

Una de las primeras decisiones fue producir código SuperBASIC claramente estructurado, incluso cuando el código ZX original no lo está explícitamente.

En ZX BASIC es habitual encontrar varias sentencias en la misma línea, separadas por dos puntos (:). Por ejemplo:

PRINT A: LET B=B+1 : LET col=col+1

  PRINT A
  LET B=B+1
  LET col=col+1

Cada sentencia pasa a ocupar su propia línea. El caso más significativo es el IF. En ZX BASIC no existen ELSE ni END IF, y un IF puede contener múltiples sentencias en una sola línea. El generador transforma esta construcción en un bloque explícito:

• una línea con la condición IF,
• una línea por cada sentencia interna,
• un END IF final.

IF A>10: PRINT A: LET B=B+1

IF A>10 THEN
  PRINT A
  LET B=B+1
END IF

Esta decisión no se tomó por comodidad, sino para garantizar: 

• Claridad semántica
• Coherencia estructural
• Facilidad de mantenimiento
• Posibilidad de posteriores optimizaciones. 

3. Numeración, control del flujo y bloques

Para poder descomponer líneas múltiples en sentencias independientes, el generador debe modificar la numeración de las líneas.

La estrategia empleada consiste en tomar el número de línea origianl del ZX Basic y añadir un contador de dos dígitos. Así, una línea con varias sentencias se expande de forma determinista.

Por ejemplo, a partir del código ZX:

    150 LET A=3 : LET C=5 : GOTO 532

El generador produce:

    15000 LET A=3
    15001 LET C=5
    15002 GOTO 53200

Estos números no siempre son válidos para el QL (en ZXBasic los números van del 1 al 9999, en SuperBASIC del 1 al 32525), pero esa no es responsabilidad del generador. El renumerador posterior se encargará de normalizarlos.

El generador mantiene contexto suficiente para abrir y cerrar bloques, producir saltos coherentes y dejar el programa en un estado funcional, aunque todavía no directamente cargable.

El generador sí garantiza que:

• los saltos son coherentes
• los bloques se abren y cierran correctamente
• el programa resultante es estructuralmente consistente.

Para el generador la numeración es solo una herramienta provisional. Se usa como andamio mientras se construye el programa final.

4. Instrucciones no portables

ZX BASIC y SuperBASIC difieren profundamente en áreas clave como:

• Salida de texto (PRINT)
• Gestión del cursor
• Colores y atributos
• Caracteres gráficos
• Sistema de coordenadas y gráficos

Una traducción directa de estas instrucciones produciría programas que “funcionan”, pero cuyo comportamiento se aleja mucho del ZX Spectrum original.

El generador asume explícitamente que estas instrucciones no son directamente portables y evita resolverlas de forma incorrecta.

5. Convención FN_ y desacoplo

Para manejar instrucciones sin equivalencia directa, el generador adopta una convención clara y sistemática: emitir llamadas a funciones o procedimientos con prefijo FN_. 

El generador: 

• No implementa su comportamiento
• Se limita a transformar el código
• La semántica se decide posteriormente

Por ejemplo, en lugar de generar directamente:

    BIN 11001101

como el comando BIN no existe en SuperBASIC, el generador produce:

    FN_BIN(11001101)

De este modo, el generador queda completamente desacoplado de la implementación concreta de estas funciones, manteniendo el sistema limpio y extensible.

6. Inicialización e inclusión de funciones FN_

Durante la generación, el sistema mantiene una lista de todas las funciones FN_ que ha utilizado durante el proceso de conversión. Al finalizar la generación, solo se incluyen aquellas funciones que han sido realmente necesarias, evitando así añadir código innecesario al programa final.

Además, el programa resultante se completa con varias secciones fijas, que quedan organizadas de la siguiente manera:

1. Un bloque de inicio del sistema, que realiza una llamada a la función FN_INIT.
2. El código convertido desde ZX BASIC a SuperBASIC.
3. Si es necesario, una línea STOP que marca explícitamente el final del programa ZX.
4. Las funciones FN_ que han sido detectadas como necesarias durante la generación.
5. La implementación de FN_INIT

La función FN_INIT se encarga de preparar el entorno de ejecución en el QL: establece el modo de pantalla, crea una ventana de 32×24 caracteres y aplica una configuración básica que permite que el programa se ejecute de forma coherente y predecible.

El STOP final del programa ZX BASIC se añade de forma explícita porque, en BASIC un slto a una línea fuera del rango del programa es válida y provoca implícitamente la finalización del programa. Si se detecta que una línea del programa realzia un salto fuera del rango permitido, se añade esta línea de STOP, cambiando los saltos que existan para que apunten a esta nueva línea. De esta manera:

• El programa generado se vuelve más determinista y sencillo de manejar
• Se evitan posibles problemas derivados de que un salto coincida con alguna de las líneas añadidas posteriormente para las funciones FN

7. Qué se obtiene al final

El resultado del generador es un programa SuperBASIC que:

• Es sintácticamente correcto
• Preserva la estructura lógica del ZX BASIC original
• No fuerza equivalencias incorrectas
• Explicita claramente las dependencias externas

Este programa está listo para ser renumerado, indentado y ejecutado dentro de un entorno controlado.

8. El siguiente paso inmediato

El siguiente paso tras el generador es el renumerador, que ajusta definitivamente la numeración y produce un programa cargable y ejecutable en el QL. Con este proceso de renumerción se cierra la primera fase del proyecto.

9. Más allá del generador

El verdadero reto futuro no está en el generador, sino en lo que rodea a las llamadas FN_....

Para que los programas ZX se comporten de forma reconocible, que parezca que estamos en un gomas real, es necesario proporcionar una capa de ejecución que reproduzca el entorno del Spectrum: pantalla, cursor, colores, caracteres y primitivas gráficas.

Ese componente convierte a ZX2SB en algo más que un transpilador, pero merece un análisis independiente y se abordará en otro momento.

Continuará con el renumerador…

Índice de entradas del conversor

Introducción

En una entrada previa presentamos la gramática formal del ZX BASIC del Spectrum 48K. Esa gramática define la estructura sintáctica, pero antes de poder parsear necesitamos convertir el texto en una secuencia estable y tipada de unidades mínimas: los tokens. Esta fase es el analizador léxico o lexer.

El lexer recorre el fichero carácter a carácter, identifica patrones significativos (palabras clave, variables, números, cadenas, operadores…), y los traduce en tokens autoexplicativos que el parser podrá consumir de forma determinista. 

Usaremos la estuctura de datos definida en la entrada anterior para lamcenar los Tokens de la línea y pasarlos a la siguiente fase. 

1. Analizador léxico

Definiremos primero qué resuelve y qué limitaciones tiene. La misión del lexer es sencilla de expresar y delicada de implementar:

• Convertir texto bruto en una secuencia de tokens bien definidos.
• Detectar categorías: identificadores, literales, operadores, palabras clave, etc.
• Emitir la posición exacta (línea y columna) para diagnósticos posteriores.
• Detectar errores léxicos, continuar cuando sea posible o parar con un mensaje de error adecuado.

Todo esto debe hacerse de manera rápida y predecible, especialmente en nuestro objetivo final: ejecutarlo en un Sinclair QL real, cuyas restricciones de RAM y CPU hacen inviable tokenizar todo el fichero en memoria. Por tanto el lexer trabaja por líneas y emite los tokens de la línea directamente en una estructura compacta optimizada.

2. ¿Qué es un token?

Un token es una unidad mínima y significativa. No representa un carácter, sino un símbolo lógico del lenguaje. Tiene varios atributos:

• Tipo: categoría (Identifier, Keyword, LineNumber, IntegerLiteral…)
• Lexema: texto exacto que lo originó
• Posición: línea y columna
• Longitud: caracteres consumidos

El parser solo opera sobre tokens, nunca sobre caracteres.

3. Tokens que vamos a generar

Derivados directamente de la gramática ZX BASIC formal.

3.1 Identificadores y variables

• Identifier — A, B2, COUNTER
• StringVar — A$, NAME$

3.2 Literales

• IntegerLiteral — enteros
• NumberLiteral — entero, decimal o exponencial
• StringLiteral — texto entre comillas

3.3 LineNumber

• Solo válido en columna 1
• 1 a 4 dígitos, sin 0 inicial

3.4 Operadores

• +, -, *, /, ^
• =, <>, <, >, <=, >=
• AND, OR, NOT

3.5 Separadores

• ( ) , ; :

3.6 Palabras clave

• LET, PRINT, INPUT, IF, THEN, FOR, …
• PLOT, DRAW, CIRCLE, POINT, …
• READ, DATA, RESTORE, DIM, CLS…
• REM

3.7 Comentarios

• Comment — tras REM hasta fin de línea

3.8 Control

• EOL — fin de línea
• EOFToken — fin de fichero (si se procesa completo; no usado en QL línea a línea)

4. Diagrama de bloques del analizador léxico

Flujo: leer línea → normalizar → escanear → clasificar → emitir tokens.

Diagrama de flujo del generador de tokens

4.3 Notas de implementación

• Normalizar CRLF/CR a \n.
• Keywords: case‑insensitive, se normalizan a MAYÚSCULAS.
• LineNumber solo en columna 1.
• REM: dos variantes — REM vacío o REM␠texto.
• Prioridad de operadores dobles (<=, <>, >=).
• Diagnósticos detallados y recuperación local.

5. Lexer en seudo‑código

El lexer genera la estructura de Tokens dentro de TokenData$() (un único arreglo de cadena) usando Token.Emit(tipo, lexema$, línea, columna). Al final de cada línea emite EOL.

REM ========================================================
REM  LEXER por líneas — Emite en TokenData$()
REM  Entrada: texto de la línea (linea$), número de línea (numLinea)
REM  Salida : tokens añadidos a TokenData$(), rematados con EOL
REM ========================================================

PROCEDIMIENTO Lexer.Preparar(tamInicial)
    Token.Iniciar()
    Token.Crear(tamInicial)        REM p.ej. 500
    PalabrasClave.Preparar()
FIN

FUNCIÓN Lexer.LexLine(linea$, numLinea) → (idxIni, idxFin)
    idxIni ← TokenCount + 1
    i ← 1
    L ← LEN(linea$)

    MIENTRAS i ≤ L
        REM 1) Espacios
        MIENTRAS i ≤ L Y EsEspacio(MID$(linea$, i, 1))
            i ← i + 1
        FIN MIENTRAS
        SI i > L ENTONCES ROMPER FIN SI

        c$ ← MID$(linea$, i, 1)

        REM 2) Comentario REM (resto de línea)
        SI ComienzaREM(linea$, i) ENTONCES
            lex$ ← MID$(linea$, i)
            Token.Emit(T_REM, lex$, numLinea, i)
            i ← L + 1
            SALIR MIENTRAS
        FIN SI

        REM 3) Cadena
        SI c$ = "\"" ENTONCES
            col ← i
            i ← i + 1
            ini ← i
            MIENTRAS i ≤ L Y MID$(linea$, i, 1) <> "\""
                i ← i + 1
            FIN MIENTRAS
            lex$ ← MID$(linea$, ini, i - ini)     REM sin comillas
            Token.Emit(T_STRING, lex$, numLinea, col)
            SI i ≤ L ENTONCES i ← i + 1 FIN SI
            CONTINUAR MIENTRAS
        FIN SI

        REM 4) Número
        SI EsDigito(c$) ENTONCES
            col ← i
            ini ← i
            MIENTRAS i ≤ L Y EsDigito(MID$(linea$, i, 1))
                i ← i + 1
            FIN MIENTRAS
            esReal ← FALSO
            SI i ≤ L Y MID$(linea$, i, 1) = "." ENTONCES
                esReal ← VERDADERO
                i ← i + 1
                MIENTRAS i ≤ L Y EsDigito(MID$(linea$, i, 1))
                    i ← i + 1
                FIN MIENTRAS
            FIN SI
            lex$ ← MID$(linea$, ini, i - ini)
            SI esReal ENTONCES
                Token.Emit(T_FLOAT, lex$, numLinea, col)
            SINO
                Token.Emit(T_INT,   lex$, numLinea, col)
            FIN SI
            CONTINUAR MIENTRAS
        FIN SI

        REM 5) Identificador / Palabra clave
        SI EsLetra(c$) O c$ = "_" ENTONCES
            col ← i
            ini ← i
            MIENTRAS i ≤ L Y (EsLetraNum(MID$(linea$, i, 1)) O MID$(linea$, i, 1) = "_")
                i ← i + 1
            FIN MIENTRAS
            lex$ ← MID$(linea$, ini, i - ini)
            tipo ← PalabrasClave.Tipo(UPPER$(lex$))
            SI tipo = 0 ENTONCES
                Token.Emit(T_ID, lex$, numLinea, col)
            SINO
                Token.Emit(tipo,  lex$, numLinea, col)
            FIN SI
            CONTINUAR MIENTRAS
        FIN SI

        REM 6) Operadores dobles
        SI i < L ENTONCES
            par$ ← MID$(linea$, i, 2)
            SI par$ = "<=" ENTONCES Token.Emit(T_LE, par$, numLinea, i) : i ← i + 2 : CONTINUAR MIENTRAS FIN SI
            SI par$ = ">=" ENTONCES Token.Emit(T_GE, par$, numLinea, i) : i ← i + 2 : CONTINUAR MIENTRAS FIN SI
            SI par$ = "<>" ENTONCES Token.Emit(T_NE, par$, numLinea, i) : i ← i + 2 : CONTINUAR MIENTRAS FIN SI
        FIN SI

        REM 7) Operadores simples / separadores
        SELECCIONAR c$
            CASO ":" : Token.Emit(T_COLON,  ":", numLinea, i)
            CASO "," : Token.Emit(T_COMMA,  ",", numLinea, i)
            CASO ";" : Token.Emit(T_SEMI,   ";", numLinea, i)
            CASO "(" : Token.Emit(T_LPAREN, "(", numLinea, i)
            CASO ")" : Token.Emit(T_RPAREN, ")", numLinea, i)
            CASO "+" : Token.Emit(T_PLUS,   "+", numLinea, i)
            CASO "-" : Token.Emit(T_MINUS,  "-", numLinea, i)
            CASO "*" : Token.Emit(T_MUL,    "*", numLinea, i)
            CASO "/" : Token.Emit(T_DIV,    "/", numLinea, i)
            CASO "^" : Token.Emit(T_POW,    "^", numLinea, i)
            CASO "=" : Token.Emit(T_EQ,     "=", numLinea, i)
            CASO "<" : Token.Emit(T_LT,     "<", numLinea, i)
            CASO ">" : Token.Emit(T_GT,     ">", numLinea, i)
            OTRO     : Token.Emit(T_ID, c$, numLinea, i)   REM desconocido, se emite tal cual
        FIN SELECCIONAR
        i ← i + 1
    FIN MIENTRAS

    Token.Emit(T_EOL, "", numLinea, L + 1)
    idxFin ← TokenCount
    RETORNAR (idxIni, idxFin)
FIN FUNCIÓN

6. Estructura de datos: arreglo único y registro empaquetado

Los tokens se almacenan en un único arreglo de cadenas (TokenData$()), cada elemento contiene un registro empaquetado binario:

CHR$(tipo) & MKI$(linea) & MKI$(columna) & CHR$(LEN(lexema$)) & lexema$ (big‑endian)

REM ========= API mínima de Tokens =========

PROCEDIMIENTO Token.Iniciar()
    Estructura_Iniciar(TokenMax, TokenCount)
FIN

PROCEDIMIENTO Token.Crear(tamInicial)
    Estructura_Crear(TokenMax, TokenCount, tamInicial, tipo.Principal)
    DIM TokenData$(TokenMax)
FIN

PROCEDIMIENTO Token.Ampliar(nuevoTamaño)
    Estructura_AmpliarArray(TokenMax, TokenCount, nuevoTamaño)
    AmpliarArray(TokenData$, TokenMax, nuevoTamaño)
    TokenMax ← nuevoTamaño
FIN

PROCEDIMIENTO Token.Reset()
    SI TokenMax = 0 ENTONCES Token.Crear(50)
    TokenCount ← 0
FIN

PROCEDIMIENTO Token.Emit(tipo, lexema$, linea, columna)
    SI TokenMax = 0 ENTONCES Token.Crear(50)
    SI TokenCount >= TokenMax ENTONCES Token.Ampliar(TokenMax + 50)
    TokenCount ← TokenCount + 1
    TokenData$(TokenCount) ← CHR$(tipo) & MKI$(linea) & MKI$(columna) & CHR$(LEN(lexema$)) & lexema$
FIN

REM ==== Acceso a campos de un registro ====
FUNCIÓN Token.GetTipo(tok$) → tipo
    RETORNAR ASC(MID$(tok$,1,1))
FIN

FUNCIÓN Token.GetLinea(tok$) → lin
    RETORNAR CVI(MID$(tok$,2,2))
FIN

FUNCIÓN Token.GetColumna(tok$) → col
    RETORNAR CVI(MID$(tok$,4,2))
FIN

FUNCIÓN Token.GetLongitudLexema(tok$) → n
    RETORNAR ASC(MID$(tok$,6,1))
FIN

FUNCIÓN Token.GetLexema(tok$) → s$
    n ← ASC(MID$(tok$,6,1))
    RETORNAR MID$(tok$,7,n)
FIN

7. El programa generado en Visual Basic .NET

Como ya he dicho (lo repito aquí por si entras directamente a esta entrada), el prototipo se desarrolla en VB.NET por velocidad y facilidad de depuración, y luego se portará a SuperBasic, manteniendo el mismo algoritmo y estructura de datos.Por ejemplo en QL podemos esribir

REM Esqueleto QL de lectura por líneas
OPEN #3, "program.bas"
numLinea ← 0
REPEAT
  L$ = LINE INPUT(#3)
  numLinea ← numLinea + 1
  (i0,i1) ← Lexer.LexLine(L$, numLinea)
  REM ... pasar (i0,i1) al parser ...
UNTIL EOF(#3)
CLOSE #3

El proyecto del transpilador (hasta donde esté desarrollado) está en GitHub: ZX2SB.

Notas rápidas

• EOL normalizado a \n.
• Keywords en mayúsculas.
• LineNumber solo en columna 1.
• REM: variantes válidas documentadas.
• Números: entero, fracción y exponente.
• Verbose: opción para depurar mostrando los tokens en pantalla

Índice de entradas del conversor

20/03/2026 Cambios en el esquema de directorios en rojo

Transpilador ZX BASIC → SuperBasic
Dos versiones en paralelo: Moderno y QL

En las últimas entradas hemos avanzado en el diseño interno del transpilador ZX BASIC → SuperBasic, definiendo estructuras de datos, el sistema de tokens y un Lexer optimizado para ejecutarse en un Sinclair QL real. Durante ese proceso me ha surgido una idea interesante para quienes quieran usar este proyecto no solo como herramienta, sino también para aprender sobre compiladores.

Vamos a generar dos versiones del transpilador en paralelo

El objetivo es disponer de dos rutas de ejecución simultáneas, una preparada para migrar a SuperBASIC, y la otra usando elementos actuales. Ambas conviven dentro del mismo proyecto. La mayoría de procesos son comunes, por lo que es sencillo ver cómo pasar de una a otra. Además incluyo una pantalla donde puedes seleccionar cuál quieres lanzar.

1) Versión Moderna

Diseñada para:

• Usar estructuras avanzadas de .NET (List, Dictionary, etc.).
• Desarrollo más rápido, depuración más cómoda y diagnósticos completos.
• Actuar como referencia clara del algoritmo general.

2) Versión compatible con SuperBasic

Implementa las estructuras reales que usará la versión final del QL:

• TokenBuffer como arreglo dinámico de registros empaquetados.
• Formato big‑endian de 16 bits, igual que el Motorola 68008.
• Procesos simples y lineales, estilo SuperBasic.

Esta versión sirve como puente entre .NET moderno y la implementación final en un QL real.

¿Por qué dos versiones?

✔ Didáctica

Muestra cómo implementar un compilador moderno y cómo trasladarlo a una plataforma retro con limitaciones reales.

✔ Validación de algoritmos

Al ejecutar ambos motores en paralelo es fácil encontrar divergencias antes de portar código al QL real.

✔ Documentación y mantenimiento

Permite explicar y probar Lexer, Parser, Semántico y Emitter tanto desde un enfoque moderno como desde un enfoque retro.

Pantalla lanzadora

Incluyo una interfaz WinForms que permite seleccionar:

• Modo: Moderno o QL‑Prep
• Ruta y nombre del fichero BASIC
• Modo Verbose

El lanzador invoca automáticamente el director correspondiente con las opciones necesarias.

Arquitectura del proyecto

El proyecto utiliza .NET Framework 4.8 para asegurar compatibilidad con Windows 7/8/10/11 y aprovechar WinForms clásico. Para quienes pidan Windows XP, 95 o 3.11… lo siento, ¡aún no he retrocedido tanto! (Aunque con lo voluble que soy, cualquiera sabe si un día aparece una versión en Turbo‑C o Turbo Pascal 😄). 

He tenido que ajustar otra vez la estructura de directorios del proyecto, ya que no se generaban las cosas en su lugar correcto, he dividido el proyecto en tres, lanzador, moderno y QL, cada uno es un proyecto independiente que genera su propio EXE, así es mas sencillo manejarlo de manera independiente. 

Estructura general del proyecto:

ZX2SB
│
├── ZX2SB.sln
├── README.md
│
├── Lanzador
│   ├── Lanzador.vbproj
│   └── src
│       ├── frmLanzador.vb
│       ├── frmLanzador.Designer.vb
│       ├── frmLanzador.resx
│       └── ... otros
│
├── Moderno
│   ├── Moderno.vbproj
│   └── src
│       ├── 01_Director.vb
        └── ... otros
└── QL
    ├── QL.vbproj
    └── src
        ├── 01_Director.vb
        └── ... otros

Conclusión

A partir de ahora el desarrollo continúa en dos líneas paralelas:

• Moderno: claridad, pruebas y comodidad.
• QL‑Prep: compatibilidad y preparación para SuperBasic.

Ambas serán documentadas paso a paso en el blog. Por ahora ya está la estructura base en el repositorio GIT del proyecto, y los directores están preparados para llamar a los procesos (que de momento solo muestran un mensaje en pantalla).

En un transpilador o un compilador clásico, el analizador semántico es la fase encargada de comprobar que un programa, además de estar bien escrito desde el punto de vista sintáctico, tiene sentido.

En el proyecto ZX2SB, cuyo objetivo es convertir código ZX BASIC a otro lenguaje, en nuestro caso SuperBASIC del QL, el analizador semántico juega un papel fundamental: es el encargado de interpretar el significado real del programa.

Las fases de un transpilador

Antes de entrar en detalle, conviene situar el analizador semántico dentro del proceso completo:

Código fuente ZX BASIC
        |
        v
  Analizador léxico (Lexer)
        |
        v
 Analizador sintáctico (Parser)
        |
        v
 Analizador semántico (Semantic)
        |
        v
 Generador de código
        |
        v
 Código destino (SuperBASIC)

Cada fase tiene una responsabilidad clara y bien delimitada.

• Lexer: convierte texto en tokens.
• Parser: verifica la estructura gramatical.
• Semantic: verifica el significado del programa.
• Generator: produce el código destino.

Qué hace exactamente el analizador semántico

El analizador semántico responde a preguntas como:

• ¿Se usa una variable antes de asignarle un valor?
• ¿Se asigna una cadena a una variable numérica?
• ¿Un NEXT corresponde a su FOR?
• ¿Hay un RETURN sin GOSUB previo?
• ¿Las instrucciones READ tienen datos DATA suficientes?

En ZX BASIC muchas de estas situaciones están permitidas por el intérprete original, pero al convertir a otros lenguajes conviene detectarlas y, al menos, avisar.

Diseño del analizador semántico en ZX2SB

El analizador semántico de ZX2SB trabaja en dos pasadas sobre un formato intermedio (IR):

1. Primera pasada: recolección de información.
2. Segunda pasada: análisis semántico y generación del IR final.

Primera pasada: recolección

En esta fase no se genera código. Se recopila información global:

• Variables existentes y su tipo (numéricas o de cadena).
• Uso de instrucciones especiales (PRINT, READ, DATA, AT, etc.).
• Estructura del programa (FOR/NEXT, GOSUB/RETURN).
• Mapa de líneas para referencias posteriores.

Esta información se guarda en un contexto semántico que se utiliza en la segunda pasada.

Segunda pasada: análisis y emisión

En la segunda pasada se analiza cada sentencia individualmente:

• Se validan tipos.
• Se marcan variables como usadas o asignadas.
• Se detectan errores y avisos.
• Se emite el IR normalizado que usará el generador.

Errores y warnings: emisión inmediata

Inicialmente, el analizador semántico acumulaba errores y avisos en listas internas. Sin embargo, en ZX2SB se ha optado por un diseño más simple y coherente:

• Los errores y warnings se emiten en el momento en que se detectan.
• La decisión de continuar o abortar se basa en las opciones del usuario.
• Se eliminan listas auxiliares innecesarias.

Esto unifica el comportamiento con el Lexer, el Parser y el Generator.

Diagrama del flujo del analizador semántico

+-----------------------------+
| Inicializar contexto        |
+-------------+---------------+
              |
              v
+-----------------------------+
| Primera pasada              |
| - Variables                 |
| - DATA / READ               |
| - Estructura                |
+-------------+---------------+
              |
              v
+-----------------------------+
| Segunda pasada              |
| - Analizar sentencias       |
| - Emitir errores/warnings   |
| - Generar IR normalizado    |
+-------------+---------------+
              |
              v
+-----------------------------+
| Resultado semántico         |
+-----------------------------+

Ejemplo de seudocódigo

El siguiente seudocódigo resume el funcionamiento básico:

function EjecutarSemantico():
    inicializar_contexto()

    primera_pasada()
    if error_fatal:
        salir

    segunda_pasada()
    emitir_warnings_variables()

Y el análisis de una sentencia concreta:

function AnalizarLET(sentencia):
    comprobar_formato()
    comprobar_variable()
    comprobar_tipos()
    marcar_asignación()
    emitir_IR()

Por qué es importante esta fase

El analizador semántico es el lugar ideal para:

• Detectar errores lógicos tempranamente.
• Dar avisos útiles sin romper compatibilidad con ZX BASIC.
• Preparar el código para distintos lenguajes destino.
• Mantener el generador lo más simple posible.

Gracias a esta fase, ZX2SB puede crecer en el futuro hacia nuevos backends (solo cambiando el generador) manteniendo una base sólida.

Conclusión

El analizador semántico es mucho más que una comprobación adicional: es el puente entre la sintaxis y el significado.

En ZX2SB se ha diseñado de forma clara, estructurada y cercana al espíritu de los lenguajes clásicos, facilitando tanto el mantenimiento como la extensión del proyecto.

En próximas entradas profundizaremos en el generador de código y en cómo las decisiones semánticas influyen directamente en el resultado final.

Índice de entradas del conversor

El Analizador Sintáctico (Parser) en un Transpilador ZX BASIC

Cómo funciona el Parser en ZX2SB y por qué es una pieza clave en la conversión de ZX BASIC

Índice

• ¿Qué es un Analizador Sintáctico?
• El flujo general del transpilador
• Qué hace exactamente un Parser
• ZX BASIC y la necesidad de un Parser tolerante
• Diseño del Parser en ZX2SB
• Diagrama del proceso del Parser
• Gestión de errores y warnings
• Ejemplo de seudocódigo
• Relación con el Analizador Semántico
• Conclusión

¿Qué es el Analizador Sintáctico (Parser)?

En un transpilador o compilador, el analizador sintáctico, normalmente llamado Parser, es la fase encargada de comprobar que un programa fuente está correctamente estructurado según la gramática del lenguaje.

En el proyecto ZX2SB, el Parser se sitúa entre el analizador léxico y el analizador semántico, actuando como un filtro estructural antes de interpretar el significado real del programa.

El flujo general del transpilador

Código fuente ZX BASIC
|
v
  Analizador léxico (Lexer)
|
v
 Analizador sintáctico (Parser)
|
v
 Analizador semántico
|
v
 Generador de código

Cada fase tiene una responsabilidad clara y no solapa funciones con las demás.

• Lexer: reconoce palabras, números, cadenas y símbolos.
• Parser: comprueba la estructura de las sentencias.
• Semantic: valida el significado y los tipos.
• Generator: produce el código destino.

Qué hace exactamente un Parser

El analizador sintáctico debe responder a preguntas como estas (pero no todas se aplican al BASIC como veremos más adelante):

• ¿La sentencia IF tiene un THEN?
• ¿Un FOR tiene su correspondiente NEXT?
• ¿La forma general de la instrucción es válida?
• ¿Los separadores y palabras clave están bien posicionados?

Es importante destacar lo que el Parser NO hace:

• No comprueba tipos de datos (eso lo hace el analizador semántico).
• No valida el uso de variables ni su significado.
• No decide si una operación es lógica o correcta.
• No genera código final.

Su misión es exclusivamente estructural.

ZX BASIC y la necesidad de un Parser tolerante

ZX BASIC es un lenguaje muy permisivo. Muchas construcciones válidas para el intérprete original pueden resultar ambiguas al convertirlas a otros lenguajes.

Por ese motivo, el Parser de ZX2SB está diseñado para:

• Aceptar la sintaxis original del ZX Spectrum.
• Detectar errores estructurales claros.
• Emitir warnings ante estructuras dudosas.
• No ser excesivamente restrictivo.

Ejemplo de programa sintácticamente válido pero lógicamente erróneo:

10 FOR i=1 TO 10
20   FOR j=1 TO 5
30     PRINT i,j
40   NEXT i
50 NEXT j

10 FOR i=1 TO 10
20   FOR j=1 TO 5 : PRINT i,j
30 NEXT i

Estos programas no genera error en BASIC clásico, pero su comportamiento no es el esperado y puede variar según el intérprete.

Diseño del Parser en ZX2SB

El Parser trabaja sobre los tokens generados por el Lexer y produce un Árbol de Sintaxis Abstracta (AST).

Dado que el objetivo final es portar el sistema a SuperBASIC, donde no existen estructuras de datos complejas, el AST se almacena como una estructura lineal intermedia (IR).

Entrada

• Secuencia de tokens.
• Números de línea originales.
• Contexto mínimo.

Salida

• Sentencias normalizadas.
• Estructura explícita del programa.
• Errores y avisos.

Diagrama del proceso del Parser

+------------------------+
| Tokens del Lexer       |
+-----------+------------+
            |
            v
+------------------------+
| Reconocer sentencias   |
| (IF, LET, FOR, PRINT)  |
+-----------+------------+
            |
            v
+------------------------+
| Verificar estructura   |
+-----------+------------+
            |
            v
+------------------------+
| Emitir IR estructurado |
+------------------------+

Gestión de errores y warnings

• Errores: la estructura es inválida.
• Warnings: la estructura es válida pero sospechosa.

La decisión de continuar o abortar depende de las opciones del usuario que se definan, no del Parser.En nuestro sistema, el usuario puede elegir entre parar y preguntar si desea continuar, o bien no parar el proceso y seguir hasta el final, los errores se verán en el fichero de log que se genera.

Ejemplo de seudocódigo

function EjecutarParser(tokens):
    for cada línea:
        identificar sentencia
        validar estructura
        emitir error o aviso
    generar IR

Relación con el Analizador Semántico

El Parser prepara el terreno para el análisis semántico, permitiendo que este se centre exclusivamente en el significado lógico.

Conclusión

El analizador sintáctico es la columna vertebral estructural del transpilador. Sin interpretar significados, garantiza que estos puedan analizarse correctamente más adelante.

En ZX2SB, el Parser respeta la filosofía del ZX BASIC original y prepara el camino para futuras transformaciones a otros lenguajes.

Índice de entradas del conversor

¿De transpilador a compilador?

Evolución del proyecto y cambio de enfoque

Cuando empecé el proyecto de transpilación de ZX BASIC a SuperBASIC (QL), el objetivo parecía claro y razonable: traducir programas clásicos del Spectrum a un SuperBASIC moderno, legible y ampliable, respetando en lo posible el espíritu original pero sin arrastrar las limitaciones del intérprete de los años 80.

Al principio pensaba que sería relativamente sencillo: tokenizar el programa y traducirlo a un lenguaje muy similar. Sin embargo, paso a paso el proyecto fue complicándose. Empezaron a aparecer casos especiales, decisiones incómodas y pequeñas incoherencias que, aunque no impedían avanzar, sí dificultaban hacerlo bien.

Sin embargo, como suele ocurrir en los proyectos que merecen la pena, el camino no fue lineal. Lo que empezó como un “simple transpilador” acabó convirtiéndose en algo conceptualmente más ambicioso: una cadena de compilación modular, con fases bien definidas, contratos explícitos y decisiones arquitectónicas conscientes.

El punto de partida: traducir, no reinterpretar

Desde el principio hubo varias decisiones claras:

• El código generado debía ser SuperBASIC editable, no un artefacto opaco.
• No se intentaría emular el ZX Spectrum al 100 %:
  • nada de PEEK / POKE
  • nada de trucos de automodificación
• Las funciones ZX no soportadas se resolverían mediante llamadas a rutinas auxiliares escritas en SuperBASIC.
• El resultado debía ser extensible, pensando en mejoras futuras.

El transpilador original funcionaba como un bloque monolítico: leer una línea, analizarla, transformarla y generar código QL.

Funcionaba, pero conforme el proyecto crecía, también crecían las dudas.

El generador fue el primer aviso

El proyecto avanzaba, con cambios en el lexer y el parser por el camino, pero fue el generador el que puso el primer escalón incómodo delante del diseño.

Para generar buen SuperBASIC había que responder a preguntas que un “transpilador rápido” no suele plantearse:

• ¿Cómo se numeran las líneas para facilitar la edición manual?
• ¿Dónde debe ir la inicialización del entorno gráfico?
• ¿Cómo se insertan subrutinas (PROC) sin romper el flujo?
• ¿Qué partes del código son infraestructura y cuáles lógica del programa?

Si el generador necesita un AST claro, el resto del sistema también debería pensarse como un compilador.

Reescribir y replantear no es perder tiempo: es ganar claridad, mantenibilidad y, muchas veces, velocidad.

La ruptura conceptual: dividir en módulos

El diseño monolítico, pensado para optimizar el QL, terminó siendo un error. La decisión clave fue:

Dividir el sistema en módulos independientes, comunicados solo por ficheros.

1. Director: orquesta el proceso, sin conocer el lenguaje.
2. Lexer: reconoce ZX BASIC y genera tokens.
3. Parser: construye el AST.
4. Semántico: valida y ajusta el AST.
5. Generador: produce SuperBASIC editable.

Primer paso: el fichero .TOK

El fichero .tok es la frontera definitiva entre fases:

• texto plano
• una línea por token
• LINE, EOL, EOF
• sin posiciones ni contexto oculto
• la única fuente de verdad para el parser

LINE 50
Keyword IF
Identifier C
OpMayorIgual >=
Number 20
Keyword THEN
Keyword GOTO
Number 100
EOL

Si algo no está en el .tok, el parser no lo sabe.

El papel del Director: menos es más

El Director no debe saber si el lenguaje es ZX BASIC, C o Pascal.

El lexer reconoce y valida el número de línea. El Director solo coordina.

El resultado: un lexer cerrado

• Reconoce ZX BASIC correctamente
• Detecta errores léxicos reales
• No adelanta semántica
• Genera un .tok definitivo

Esta fase está cerrada.

Conclusión

El proyecto ya no es solo un transpilador: es una base sólida para un posible compilador real.

El lexer está cerrado, el contrato existe, y el camino es ahora mucho más claro.

Postdata

Este proyecto es complejo y formativo. Revisar, dudar, reescribir y aprender forma parte esencial del proceso.

La ayuda de herramientas como Copilot ha sido clave, siempre revisando, cuestionando y aprendiendo.

Índice de entradas del conversor

Introducción

Para ejecutar el transpilador ZX BASIC → SuperBasic en un Sinclair QL real debemos optimizar al máximo la memoria y la velocidad. Por ello, el Lexer usará un único arreglo de cadena donde cada elemento es un token en un registro empaquetado (formato binario compacto), en lugar de varios arreglos paralelos. Esto reduce la fragmentación de memoria, simplifica las ampliaciones y acelera copias.

El objetivo de esta entrada es implementar, en seudo‑código, todas las funciones necesarias para manejar la estructura de Tokens (crear, ampliar, resetear, insertar y leer) y añadir funciones de prueba que crean registros y los verifican. Esta entrada es en seudo‑código; el desarrollo real en Visual Basic se publicará en el repositorio del proyecto.

1. Diseño del registro de Token (formato binario)

Formato de registro (TokenRecord):
CHR$(tipo) & MKI$(linea) & MKI$(columna) & CHR$(LEN(lexema$)) & lexema$

• tipo → byte (0..255).
• línea → entero sin signo de 16‑bit (2 bytes).
• columna → entero sin signo de 16‑bit (2 bytes).
• len(lexema$) → byte (0..255).
• lexema$ → cadena (longitud variable).

Compacto, rápido y alineado con el manejo de cadenas del QL.

2. Funciones MKI$ y CVI (seudocódigo compatible QL)

Aclaración sobre endianness: Para almacenar números de más de 1 byte se usan dos sistemas diferentes, según el orden en que se guardan en memoria (o en la cadena, en nuestro caso), se denomina MSB al byte más significativo del conjunto de bytes (en un número sería la parte izquierda) y LSB al menos significativo (en un número la parte derecha):

• Big‑endian (primero el byte más significativo, MSB): el número se mantiene en el orden “natural” de sus bytes, es decir, en binario puro con el MSB antes que el LSB. Es el formato nativo del 68008 (y toda la familia 680x0), y por tanto el que usa el QL. También lo emplearon arquitecturas como SPARC (en muchas implementaciones), PowerPC (en configuraciones clásicas de servidores/Unix) y ciertos sistemas IBM de gran porte. Es el formato que usaremos en nuestros procesos.
• Little‑endian (primero el byte menos significativo, LSB): el número se almacena con el orden de bytes invertido. Aunque pueda parecer menos intuitivo, favorece algunas operaciones aritméticas con acarreo al comenzar por el LSB y propagar el acarreo hacia los bytes más altos. Es el formato usado en los PC con Intel y también el predeterminado en la mayoría de sistemas ARM y RISC‑V actuales, y fue el usado en los DEC PDP .

REM ==================================================================
REM  MKI$(n) — Devuelve una cadena de 2 bytes a partir de un entero
REM            de 16 bits sin signo, en formato big-endian (MSB, LSB)
REM ==================================================================
FUNCIÓN MKI$(n) → s$
    SI n < 0 ENTONCES ERROR No se soportan negativos
    SI n > 65535 ENTONCES ERROR Número demasiado grande

    hi ← (n \ 256) MOD 256
    lo ← n MOD 256

    s$ ← CHR$(hi) & CHR$(lo)
    RETORNAR s$
FIN FUNCIÓN

REM ==================================================================
REM  CVI(s$) — Convierte una cadena de 2 bytes (big-endian)
REM            en un entero de 16 bits sin signo
REM ==================================================================
FUNCIÓN CVI(s$) → n
    hi ← ASC(MID$(s$,1,1))
    lo ← ASC(MID$(s$,2,1))
    n  ← hi*256 + lo
    RETORNAR n
FIN FUNCIÓN

3. API de gestión de Tokens

REM ============================================================
REM  TOKENS — Arreglo único de cadenas con registros empaquetados
REM  TokenData$(n), TokenCount, TokenMax
REM ============================================================

PROCEDIMIENTO Token.Iniciar()
    Estructura_Iniciar(TokenMax, TokenCount)   REM Max=0, Count=0
FIN

PROCEDIMIENTO Token.Crear(tamInicial)
    Estructura_Crear(TokenMax, TokenCount, tamInicial, tipo.Principal)
    DIM TokenData$(TokenMax)
FIN

PROCEDIMIENTO Token.Ampliar(nuevoTamaño)
    Estructura_AmpliarArray(TokenMax, TokenCount, nuevoTamaño)
    AmpliarArray(TokenData$, TokenMax, nuevoTamaño)
    TokenMax ← nuevoTamaño
FIN

PROCEDIMIENTO Token.Reset()
    SI TokenMax = 0 ENTONCES Token.Crear(50)
    TokenCount ← 0
FIN

4. Empaquetado y acceso a los datos del registro

REM =========================================
REM  Empaquetado / Acceso a campos del token
REM =========================================

FUNCIÓN Token.Encode(tipo, linea, columna, lexema$) → token$
    token$ ← CHR$(tipo) & MKI$(linea) & MKI$(columna) & CHR$(LEN(lexema$)) & lexema$
    RETORNAR token$
FIN

FUNCIÓN Token.GetTipo(token$) → tipo
    tipo ← ASC(MID$(token$, 1, 1))
    RETORNAR tipo
FIN

FUNCIÓN Token.GetLinea(token$) → linea
    linea ← CVI(MID$(token$, 2, 2))
    RETORNAR linea
FIN

FUNCIÓN Token.GetColumna(token$) → col
    col ← CVI(MID$(token$, 4, 2))
    RETORNAR col
FIN

FUNCIÓN Token.GetLongitudLexema(token$) → lenLex
    lenLex ← ASC(MID$(token$, 6, 1))
    RETORNAR lenLex
FIN

FUNCIÓN Token.GetLexema(token$) → lex$
    lenLex ← ASC(MID$(token$, 6, 1))
    lex$ ← MID$(token$, 7, lenLex)
    RETORNAR lex$
FIN

5. Alta de nuevos tokens en el arreglo

REM ==========================
REM  Alta (añadir) de un token
REM ==========================
PROCEDIMIENTO Token.Emit(tipo, lexema$, linea, columna)
    SI TokenMax = 0 ENTONCES Token.Crear(50)
    SI TokenCount >= TokenMax ENTONCES Token.Ampliar(TokenMax + 50)

    TokenCount ← TokenCount + 1
    TokenData$(TokenCount) ← Token.Encode(tipo, linea, columna, lexema$)
FIN

Esta operación codifica el registro y lo guarda como una cadena en TokenData$(n).

6. Prueba: crear registros, recuperarlos y mostrarlos

REM ============================================================
REM  PRUEBAS — Director
REM   • CLS al inicio
REM   • CrearCasos una sola vez
REM   • Emite, verifica (PRUEBA 1)
REM   • Corrompe 2 tokens ya emitidos
REM   • Muestra "=== PRUEBA 2 ===" y verifica (errores)
REM ============================================================
PROCEDIMIENTO Pruebas()
    CLS

    CrearCasos()

    REM Emisión inicial desde la base
    Token.Iniciar()
    Token.Crear(MAX(NCasos, 4))
    PARA i ← 1 HASTA NCasos
        Token.Emit(BaseTipo(i), BaseLex$(i), BaseLinea(i), BaseCol(i))
    FIN PARA

    PRINT "=== PRUEBA 1 ==="
    REM PRIMERA VERIFICACIÓN (OK)
    Verificar()

    REM Corromper sin tocar la base de esperados:
    REM  i=2: lin=99
    REM  i=5: col=99
    TokenData$(2) ← Token.Encode(BaseTipo(2), 99, BaseCol(2), BaseLex$(2))
    TokenData$(5) ← Token.Encode(BaseTipo(5), BaseLinea(5), 99, BaseLex$(5))

    PRINT
    PRINT "=== PRUEBA 2 ==="

    REM SEGUNDA VERIFICACIÓN (debe mostrar 2 errores)
    Verificar()
FIN PROCEDIMIENTO


REM ============================================================
REM  CrearCasos — Define los casos base (solo se llama una vez)
REM ============================================================
PROCEDIMIENTO CrearCasos()
    DIM BaseTipo(50)
    DIM BaseLex$(50)
    DIM BaseLinea(50)
    DIM BaseCol(50)
    NCasos ← 0

    NCasos ← NCasos + 1
    BaseTipo(NCasos)  ← 10
    BaseLex$(NCasos)  ← "PRINT"
    BaseLinea(NCasos) ← 100
    BaseCol(NCasos)   ← 1

    NCasos ← NCasos + 1
    BaseTipo(NCasos)  ← 1
    BaseLex$(NCasos)  ← "A"
    BaseLinea(NCasos) ← 100
    BaseCol(NCasos)   ← 7

    NCasos ← NCasos + 1
    BaseTipo(NCasos)  ← 30
    BaseLex$(NCasos)  ← "+"
    BaseLinea(NCasos) ← 100
    BaseCol(NCasos)   ← 9

    NCasos ← NCasos + 1
    BaseTipo(NCasos)  ← 2
    BaseLex$(NCasos)  ← "42"
    BaseLinea(NCasos) ← 100
    BaseCol(NCasos)   ← 11

    NCasos ← NCasos + 1
    BaseTipo(NCasos)  ← 20
    BaseLex$(NCasos)  ← ":"
    BaseLinea(NCasos) ← 100
    BaseCol(NCasos)   ← 13

    NCasos ← NCasos + 1
    BaseTipo(NCasos)  ← 4
    BaseLex$(NCasos)  ← "HELLO"
    BaseLinea(NCasos) ← 101
    BaseCol(NCasos)   ← 1

    NCasos ← NCasos + 1
    BaseTipo(NCasos)  ← 21
    BaseLex$(NCasos)  ← ","
    BaseLinea(NCasos) ← 101
    BaseCol(NCasos)   ← 2
FIN PROCEDIMIENTO


REM ============================================================
REM  Verificar — Solo lectura y comprobación
REM  (no crea, no emite; compara almacenamiento vs. base)
REM  Salida en varias líneas por elemento para evitar desbordes
REM ============================================================
PROCEDIMIENTO Verificar()
    PRINT "=== Verificación de tokens (NCasos="; NCasos; ") ==="

    fallos ← 0
    hasta ← MIN(TokenCount, NCasos)

    PARA i ← 1 HASTA hasta
        tok$   ← TokenData$(i)
        tipo   ← Token.GetTipo(tok$)
        lin    ← Token.GetLinea(tok$)
        col    ← Token.GetColumna(tok$)
        lenLex ← Token.GetLongitudLexema(tok$)
        lex$   ← Token.GetLexema(tok$)

        expT   ← BaseTipo(i)
        expL$  ← BaseLex$(i)
        expLi  ← BaseLinea(i)
        expCo  ← BaseCol(i)

        esOK ← (tipo = expT) Y (lin = expLi) Y (col = expCo) Y (lenLex = LEN(expL$)) Y (lex$ = expL$)

        SI esOK ENTONCES
            PRINT i; ": OK  ->"
            Ver(tipo, lin, col, lenLex, lex$)
        SINO
            fallos ← fallos + 1
            PRINT i; ": ERR ->  ESP:"
            Ver(expT, expLi, expCo, LEN(expL$), expL$)
            PRINT "               OBT:"
            Ver(tipo, lin, col, lenLex, lex$)
        FIN SI
    FIN PARA

    SI fallos = 0 ENTONCES
        PRINT "Resultado: OK ( "; hasta; " registros verificados )"
    SINO
        PRINT "Resultado: ERROR ( "; fallos; " fallos de "; hasta; " )"
    FIN SI
FIN PROCEDIMIENTO

REM ============================================================
REM  Ver — Muestra los campos del registro en líneas separadas
REM ============================================================
PROCEDIMIENTO Ver(tipo, lin, col, lenLex, lex$)
    PRINT "  tipo="; tipo
    PRINT "  lin="; lin
    PRINT "  col="; col
    PRINT "  len="; lenLex
    PRINT "  lex=["; lex$; "]"
FIN PROCEDIMIENTO

7. Siguiente paso

• Integrar estos cambios en el Lexer real (Fase 2): sustituir escrituras paralelas por Token.Emit y usar TokenData$() en el Parser con Token.Get*.
• Publicar el módulo equivalente en VB.NET (Encode/Decode + pruebas), con BitConverter e inversión a big‑endian.

En la siguiente entrega convierto este seudo‑código a VB.NET con pruebas unitarias.

Índice de entradas del conversor

Introducción

El transpilador ZX BASIC → SuperBasic que estamos desarrollando debe ejecutarse finalmente en un Sinclair QL real. Esto significa trabajar con:

• 128 KB de RAM totales (menos aún disponibles para SuperBasic),
• sin estructuras dinámicas modernas como listas, diccionarios o árboles,
• sin objetos ni clases,
• E/S muy lenta (microdrives).

Por ese motivo, todas las estructuras de datos que en VB.NET son naturales (List<T>, diccionarios, árboles, AST reales…) deben redefinirse desde cero para poder implementarse en SuperBasic.

Esta entrada documenta todas las estructuras que necesitaremos en el transpilador y proporciona un seudo‑código portable al QL. Si más adelante fuera necesario añadir otras, se hará en otra entrada.

En VB.NET usamos listas y clases por comodidad y velocidad, pero en el QL se implementará todo con los recursos disponibles. Además, esta filosofía exige encapsular las estructuras, lo cual es una buena práctica de diseño. Para mantener precisión terminológica: hablaré de arreglo unidimensional (o simplemente arreglo) para lo que habitualmente se denomina array, de arreglo multidimensional (2 o más dimensiones) para lo que habitualmente se llama Matriz para 2 dimensiones, y Matriz de n dimensiones cuando hay mas de 2 (en matemáticas, un arreglo de 3 o más dimensiones se denomina tensor).

1. Por qué necesitamos estructuras propias

SuperBasic no dispone de:

• listas dinámicas,
• arreglos redimensionables sin pérdida,
• tipos compuestos o registros,
• pilas, colas o diccionarios,
• árboles.

La única herramienta fiable son los arreglos estáticos. Por ello cada estructura del transpilador debe implementarse como arreglos más unas variables auxiliares. Los arreglos podrán crecer si es necesario.

2. Qué es un registro

En programación y en ingeniería de datos, un registro es una unidad lógica de información formada por varios campos, cada uno con un significado propio. Un registro no es un arreglo, sino un agrupador de datos relacionados que conceptualmente funcionan como una sola unidad.

En lenguajes modernos un registro sería equivalente a una “estructura” o “struct”, pero en SuperBasic del QL no existen tipos compuestos: solo disponemos de arreglos numéricos y de cadenas. Por tanto, cuando hablamos de un “registro” en este transpilador, nos referimos a un concepto abstracto que representamos usando varios arreglos paralelos o empleando un único arreglo de cadenas que contiene todos los campos empaquetados.

2.1 Campos dentro de un registro

Un registro está formado por varios valores individuales (campos). Por ejemplo, un registro para un token contiene campos como:

• tipo del token,
• lexema (cadena original),
• línea donde aparece,
• columna dentro de esa línea,
• longitud del lexema.

Todos esos campos juntos forman un solo registro Token.

2.2 Cómo representaremos un registro

Dado que SuperBasic no permite definir estructuras complejas, podemos representar un registro de dos formas posibles:

• Mediante varios arreglos paralelos: cada campo del registro se guarda en un arreglo independiente, y el índice n identifica el mismo registro en todos ellos.
• Mediante un único arreglo de cadena con los datos empaquetados: cada elemento del arreglo contiene todos los campos del registro codificados en una sola cadena, usando separadores o marcas de longitud.

Ambos métodos expresan el mismo concepto: un registro es un conjunto de campos que pertenecen juntos, y que se accede siempre por un mismo índice. El formato exacto de representación dependerá de la estructura (Tokens, Diagnósticos, Tabla de líneas, etc.).

Con esta definición, cuando hablemos de “crear un registro”, “ampliar un registro” o “acceder a un registro”, nos referiremos siempre a estas unidades lógicas que agrupamos en una cadena y almacenamos mediante arreglos.

2.3 Formatos de empaquetado para registros

Para representar un registro dentro de un arreglo de cadenas en SuperBasic, existen varias técnicas de empaquetado. Cada una equilibra de forma distinta la ocupación en memoria, la velocidad de acceso y la facilidad de decodificación. En el transpilador adoptaremos tres estilos según la estructura a almacenar.

• A) Separadores entre campos (p. ej. "3|A$|120|5|2"): legible y sencillo, adecuado para estructuras poco críticas en rendimiento.
• B) Campos de tamaño fijo: rápido de extraer mediante MID$, aunque menos flexible y con espacio desaprovechado.
• C) Longitud + campo (formato binario compacto):
  CHR$(tipo) & MKI$(linea) & MKI$(col) & CHR$(LEN(lex$)) & lex$
  Es el método más rápido y más eficiente para estructuras que se consultarán miles de veces.

En este artículo, para cada estructura del transpilador indicaré explícitamente el formato de registro que utilizará, detallando los nombres de los campos, su tipo y cómo se empaquetan en la cadena final.

3. Almacenamiento de cadenas en el QL real

El SuperBasic del Sinclair QL no almacena cadenas dentro del arreglo como hacía ZX BASIC (espacio fijo por elemento), ni usa arreglos de punteros al estilo C. Cada elemento de un arreglo de cadenas contiene un descriptor (puntero + longitud), y el texto vive en el heap dinámico del QDOS.

3.1 ¿Qué hay realmente en un arreglo de cadenas?

Cuando declaramos un arreglo de cadenas como:

DIM A$(9)
A$(0) = "HOLA"
A$(1) = "QL"
A$(2) = ""
A$(3) = "TRANS"

El QL reserva 10 descriptores (índices 0 a 9), y cada descriptor contiene dos valores:

• un puntero a la cadena real almacenada en el heap del QDOS,
• la longitud de esa cadena.

Por tanto, tras las asignaciones, la estructura interna del arreglo es:

A$(0)  = descriptor (puntero, 4)  → "HOLA"
A$(1)  = descriptor (puntero, 2)  → "QL"
A$(2)  = descriptor (puntero, 0)  → ""
A$(3)  = descriptor (puntero, 5)  → "TRANS"
A$(4)  = descriptor (puntero, 0)  → ""
A$(5)  = descriptor (puntero, 0)  → ""
A$(6)  = descriptor (puntero, 0)  → ""
A$(7)  = descriptor (puntero, 0)  → ""
A$(8)  = descriptor (puntero, 0)  → ""
A$(9)  = descriptor (puntero, 0)  → ""

Obsérvese que ninguna cadena se guarda dentro del arreglo. Solo se almacena un descriptor por elemento; el texto vive siempre en el heap, lo que permite ampliar o copiar arreglos de cadenas de forma rápida (solo se copian punteros).

4. Comparativa de modelos de estructuras en SuperBasic

Existen varias maneras diferentes de almacenar los valores de nuestras estructuras en arreglos dentro del QL:

4.1 Varios arreglos paralelos

• Qué es: un arreglo por cada campo de la estructura (p. ej., TokenType(), TokenLexema$()…).
• Ventajas: acceso rápido; depuración clara.
• Inconvenientes: hay que ampliar/copiar varios arreglos; más fragmentación con muchos campos de texto.
• Uso: recomendable para AST y estructuras con enlaces.

4.2 Arreglo multidimensional

• Qué es: DIM Datos(N, M) (numérico).
• Límite: con cadenas no resuelve el problema; seguiría siendo necesario otro arreglo $.
• Uso: no recomendado para nuestras estructuras con texto.

4.3 Un único arreglo de cadena con los datos empaquetados

• Qué es: Datos$() donde cada elemento empaqueta campos (tipo, línea, col., lexema…).
• Ventajas: se amplía y copia un solo arreglo; menos fragmentación.
• Inconvenientes: hay que empaquetar/desempaquetar; ligera penalización de CPU.
• Uso: muy adecuado para Tokens, Diagnósticos, Símbolos, Tabla de líneas y Salida.

5. Estructuras de datos del transpilador

Las estructuras necesarias son:

• Lista de Tokens — salida del Lexer.
• Árbol de Sintaxis Abstracta (AST) — salida del Parser.
• Tabla de Líneas — usada por el Semántico.
• Tabla de Símbolos — variables y arreglos.
• Tabla de Diagnósticos — errores por fases.
• Buffer de Salida — líneas SuperBasic generadas.

Todas deben existir en VB.NET y en SuperBasic, con forma conceptual idéntica.

6. Descripción detallada de cada estructura

En un QL real debemos optimizar al máximo memoria y tiempo de acceso. Por ello, en cada estructura emplearemos la mejor representación posible: registros empaquetados en un único arreglo de cadena cuando primen eficiencia y sencillez, y arreglos paralelos cuando la estructura sea jerárquica (AST) y requiera enlaces explícitos entre nodos.

6.1 Tokens (Lexer)

6.1.1 Representación

Un único arreglo de cadenas empaquetadas (formato binario compacto) por token:

TokenData$(n)
TokenCount
TokenMax

6.1.2 Registro: TokenRecord

Campo        : Tipo
Tipo de dato : byte (0..255)
Descripción  : Categoría del token (Identifier, Keyword, etc.)
Almacenado   : CHR$(tipo)

Campo        : Línea
Tipo de dato : entero corto (2 bytes)
Descripción  : Nº de línea física en el fichero de entrada
Almacenado   : MKI$(linea)

Campo        : Columna
Tipo de dato : entero corto (2 bytes)
Descripción  : Columna (1‑based) donde comienza el token
Almacenado   : MKI$(columna)

Campo        : LongitudLexema
Tipo de dato : byte (0..255)
Descripción  : Longitud del lexema en caracteres
Almacenado   : CHR$(LEN(lexema$))

Campo        : Lexema
Tipo de dato : cadena (longitud variable)
Descripción  : Texto literal del token
Almacenado   : lexema$

6.1.3 Empaquetado

TokenData$(n) =
  CHR$(tipo) &
  MKI$(linea) &
  MKI$(columna) &
  CHR$(LEN(lexema$)) &
  lexema$

6.2 AST por línea (Parser)

6.2.1 Representación

El AST (línea, sentencias y expresiones) es una estructura jerárquica. Para mantener los enlaces entre nodos y recorrer el “árbol” con claridad y rapidez en QL, se usarán varios arreglos paralelos.

6.2.2 Nodo de Línea

ASTLine_Number(id)     → Nº de línea ZX BASIC
ASTLine_StmtIndex(id)  → Primer índice en Stmt*
ASTLine_StmtCount(id)  → Nº de sentencias en la línea
ASTLineCount           → Nº real de nodos de línea
ASTLineMax             → Capacidad reservada

6.2.3 Sentencias

StmtType(n)            → Tipo de sentencia (LET, PRINT, IF, ...)
StmtParam1$(n)         → Parámetro textual principal (p. ej. destino en LET)
StmtParam2$(n)         → Segundo parámetro textual (si aplica)
StmtExprIndex(n)       → Índice en Expr* de la expresión asociada (0 si no hay)
StmtCount              → Nº real de sentencias
StmtMax                → Capacidad reservada

6.2.4 Expresiones

ExprType(n)            → Literal, VarRef, Unary, Binary, FuncCall, Paren...
ExprValue$(n)          → Valor textual asociado (variable, número, nombre)
ExprLeft(n)            → Índice de subexpresión izquierda (0 si no aplica)
ExprRight(n)           → Índice de subexpresión derecha (0 si no aplica)
ExprCount              → Nº real de expresiones
ExprMax                → Capacidad reservada

6.3 Tabla de Líneas (Semántico)

6.3.1 Representación

Un único arreglo de cadenas con separadores (legible y suficiente en rendimiento):

LineData$(n)   = numeroLinea$ & "|" & astIndex$
LineCount
LineMax

6.3.2 Registro: LineRecord

Campo        : NumeroLinea
Tipo de dato : entero (en texto)
Descripción  : Nº de línea ZX BASIC existente en el programa
Almacenado   : "1234"

Separador1   : "|"
Tipo de dato : carácter (longitud fija = 1)
Descripción  : Separador de campos
Almacenado   : "|"

Campo        : ASTIndex
Tipo de dato : entero (en texto)
Descripción  : Índice en las tablas ASTLine_* para esa línea
Almacenado   : "57"

6.4 Tabla de Símbolos

6.4.1 Representación

Un único arreglo de cadenas con separadores:

SymbolData$(n) = nombre$ & "|" & tipo$
SymbolCount
SymbolMax

6.4.2 Registro: SymbolRecord

Campo        : Nombre
Tipo de dato : cadena (longitud variable)
Descripción  : Identificador del símbolo (A, A$, ARR(), ...)
Almacenado   : "A$"

Separador1   : "|"
Tipo de dato : carácter (longitud fija = 1)
Descripción  : Separador de campos
Almacenado   : "|"

Campo        : Tipo
Tipo de dato : cadena corta
Descripción  : Clasificación (p. ej. "NUM", "STR", "ARR_NUM", "ARR_STR")
Almacenado   : "STR"

6.5 Diagnósticos

6.5.1 Representación

Un único arreglo de cadenas con separadores:

DiagData$(n) = mensaje$ & "|" & linea$ & "|" & columna$ & "|" & fase$
DiagCount
DiagMax

6.5.2 Registro: DiagRecord

Campo        : Mensaje
Tipo de dato : cadena (longitud variable)
Descripción  : Texto del diagnóstico (error/aviso)
Almacenado   : "Invalid token '£'"

Separador1   : "|"
Tipo de dato : carácter
Descripción  : Separador
Almacenado   : "|"

Campo        : Línea
Tipo de dato : entero (en texto)
Descripción  : Nº de línea física (0 si global)
Almacenado   : "123"

Separador2   : "|"
Tipo de dato : carácter
Descripción  : Separador
Almacenado   : "|"

Campo        : Columna
Tipo de dato : entero (en texto)
Descripción  : Columna asociada (0 si no aplica)
Almacenado   : "17"

Separador3   : "|"
Tipo de dato : carácter
Descripción  : Separador
Almacenado   : "|"

Campo        : Fase
Tipo de dato : cadena corta
Descripción  : "Lexer", "Parser", "Semántico", "Transformador", "Emisor"
Almacenado   : "Lexer"

6.6 Buffer de salida

6.6.1 Representación

Un único arreglo de cadenas donde cada elemento es la línea destino completa:

Output$(n)    = lineaSuperBasic$
OutputCount
OutputMax

6.6.2 Registro: OutputRecord

Campo        : LineaSB
Tipo de dato : cadena (longitud variable)
Descripción  : Línea completa ya generada en SuperBasic
Almacenado   : "100 PRINT \"HOLA\""

7. Seudo‑código de las estructuras

Convención: var X = parámetro por referencia (modifica el valor externo). X sin var = parámetro por valor.

7.0 Funciones genéricas para usar arreglos como lista

Seudo‑código que expresa el comportamiento lógico (no es SuperBasic literal):

// ======================================================================
//  FUNCIONES AUXILIARES GENÉRICAS PARA TODAS LAS ESTRUCTURAS
// ======================================================================

// Reset de estructura (mantiene arreglos, Count=0)
PROCEDIMIENTO Estructura_Reset(var Count)
    Count ← 0
FIN

// Crear estructura con tamaño inicial
PROCEDIMIENTO Estructura_Crear(var Max, var Count, tamInicial, tipo)
    SI tipo = tipo.Principal ENTONCES
        Crear_Arrays(tamInicial)  // Arreglos definitivos
        Max   ← tamInicial
        Count ← 0
    SINO
        Crear_ArraysAuxiliares(tamInicial)  // Arreglos temporales
    FIN SI
FIN

// Ampliar estructura a un nuevo tamaño absoluto
PROCEDIMIENTO Estructura_AmpliarArray(var Max, var Count, nuevoTamaño)
    SI nuevoTamaño <= Max ENTONCES
        RETORNAR
    FIN SI

    // Crear arreglos auxiliares y copiar
    Estructura_Crear(auxMax, auxCount, nuevoTamaño, tipo.Auxiliar)
    Copiar_Arrays(array_Actual, array_Temporal)

    // Crear nuevos arreglos principales ampliados y restaurar
    Estructura_Crear(Max, Count, nuevoTamaño, tipo.Principal)
    Copiar_Arrays(array_Temporal, array_Actual)

    Max ← nuevoTamaño
FIN

7.X Firmas de funciones por estructura (sin implementación)

// TOKENS
PROCEDIMIENTO Token_Iniciar()
PROCEDIMIENTO Token_Crear(tamInicial)
PROCEDIMIENTO Token_Ampliar(nuevoTamaño)
PROCEDIMIENTO Token_Reset()
PROCEDIMIENTO Token_Add(tipo, lexema$, linea, columna, longitud)

// AST
PROCEDIMIENTO AST_Iniciar()
PROCEDIMIENTO AST_Crear(tamInicial)
PROCEDIMIENTO AST_Ampliar(nuevoTamaño)
PROCEDIMIENTO AST_Reset()
FUNCIÓN       AST_NewLine(lineNumber) → idLinea
FUNCIÓN       AST_AddStatement(idLinea, tipoStmt) → idStmt

// SENTENCIAS
PROCEDIMIENTO Stmt_Iniciar()
PROCEDIMIENTO Stmt_Crear(tamInicial)
PROCEDIMIENTO Stmt_Ampliar(nuevoTamaño)
PROCEDIMIENTO Stmt_Reset()
FUNCIÓN       Stmt_Add(tipoStmt, param1$, param2$, exprIndex) → idStmt

// EXPRESIONES
PROCEDIMIENTO Expr_Iniciar()
PROCEDIMIENTO Expr_Crear(tamInicial)
PROCEDIMIENTO Expr_Ampliar(nuevoTamaño)
PROCEDIMIENTO Expr_Reset()
FUNCIÓN       Expr_Add(tipoExpr, valor$, leftIndex, rightIndex) → idExpr

// TABLA DE LÍNEAS
PROCEDIMIENTO LineTable_Iniciar()
PROCEDIMIENTO LineTable_Crear(tamInicial)
PROCEDIMIENTO LineTable_Ampliar(nuevoTamaño)
PROCEDIMIENTO LineTable_Reset()
PROCEDIMIENTO LineTable_Insert(lineNumber, idLinea)

// SÍMBOLOS
PROCEDIMIENTO Symbol_Iniciar()
PROCEDIMIENTO Symbol_Crear(tamInicial)
PROCEDIMIENTO Symbol_Ampliar(nuevoTamaño)
PROCEDIMIENTO Symbol_Reset()
PROCEDIMIENTO Symbol_Add(nombre$, tipo)

// DIAGNÓSTICOS
PROCEDIMIENTO Diag_Iniciar()
PROCEDIMIENTO Diag_Crear(tamInicial)
PROCEDIMIENTO Diag_Ampliar(nuevoTamaño)
PROCEDIMIENTO Diag_Reset()
PROCEDIMIENTO Diag_Add(msg$, linea, columna, fase$)

// SALIDA
PROCEDIMIENTO Output_Iniciar()
PROCEDIMIENTO Output_Crear(tamInicial)
PROCEDIMIENTO Output_Ampliar(nuevoTamaño)
PROCEDIMIENTO Output_Reset()
PROCEDIMIENTO Output_Add(linea$)

7.1 Tokens (implementacióncompleta en seudo‑código como ejemplo)

PROCEDIMIENTO Token_Iniciar()
    Estructura_Iniciar(TokenMax, TokenCount)
FIN

PROCEDIMIENTO Token_Crear(tamInicial)
    Estructura_Crear(TokenMax, TokenCount, tamInicial, tipo.Principal)
    DIM TokenType(TokenMax)
    DIM TokenLexema$(TokenMax)
    DIM TokenLine(TokenMax)
    DIM TokenColumn(TokenMax)
    DIM TokenLength(TokenMax)
FIN

PROCEDIMIENTO Token_Ampliar(nuevoTamaño)
    Estructura_AmpliarArray(TokenMax, TokenCount, nuevoTamaño)
    AmpliarArray(TokenType,    TokenMax, nuevoTamaño)
    AmpliarArray(TokenLexema$, TokenMax, nuevoTamaño)
    AmpliarArray(TokenLine,    TokenMax, nuevoTamaño)
    AmpliarArray(TokenColumn,  TokenMax, nuevoTamaño)
    AmpliarArray(TokenLength,  TokenMax, nuevoTamaño)
    TokenMax ← nuevoTamaño
FIN

PROCEDIMIENTO Token_Reset()
    SI TokenMax = 0 ENTONCES
        Token_Crear(50)
    FIN SI
    TokenCount ← 0
FIN

PROCEDIMIENTO Token_Add(tipo, lexema$, linea, columna, longitud)
    SI TokenMax = 0 ENTONCES
        Token_Crear(50)
    FIN SI
    SI TokenCount >= TokenMax ENTONCES
        Token_Ampliar(TokenMax + 50)
    FIN SI
    TokenCount ← TokenCount + 1
    TokenType(TokenCount)    ← tipo
    TokenLexema$(TokenCount) ← lexema$
    TokenLine(TokenCount)    ← linea
    TokenColumn(TokenCount)  ← columna
    TokenLength(TokenCount)  ← longitud
FIN

8. Siguientes pasos

Ya tenemos la base necesaria para portar todas las fases del transpilador al QL:

• Lexer por líneas,
• Parser por líneas,
• Semántico con tabla de líneas y validaciones globales,
• Transformaciones ZX→SuperBasic,
• Generación del programa destino.

En la próxima entrada comenzaremos con el lexer por líneas, construyendo las estructuras definidas aquí.

Índice de entradas del conversor

Introducción

Hasta ahora hemos desarrollado la gramática formal del ZX BASIC. El siguiente paso lógico es diseñar una pieza clave en cualquier compilador o transpilador: el Director del Proceso, responsable de coordinar lectura, análisis y generación. Dado que el objetivo final es ejecutar en un Sinclair QL real —un entorno con CPU más lenta y RAM muy limitada— adaptamos el diseño para que sea rápido y de mínimo consumo de memoria.

1. Motivación del Director del Proceso

Aunque cada fase del transpilador se puede ejecutar por separado, lo ideal es disponer de un módulo que:

• Controle el orden correcto de ejecución.
• Transmita la salida de cada fase a la siguiente.
• Gestione errores y diagnósticos desde un único punto.
• Permita activar/desactivar opciones (verbose, políticas del charset…).
• Se adapte al destino: en nuestro caso, el QL, que requiere memoria mínima.

2. Pipeline completo del transpilador

FASE 01 — DEFINICIÓN PRECISA DEL LENGUAJE
FASE 02 — DIRECTOR DEL PROCESO
FASE 03 — LÉXICO (TOKENIZER)
FASE 04 — SINTÁCTICO (PARSER LL(1))
FASE 05 — ANÁLISIS SEMÁNTICO
FASE 06 — TRANSFORMACIONES (ZX BASIC → SuperBasic)
FASE 07 — GENERACIÓN DE CÓDIGO SuperBasic
FASE 08 — OPTIMIZACIÓN
FASE 09 — SALIDA + TESTS
FASE 10 — EMPAQUETADO Y HERRAMIENTAS
FASE 11 — DOCUMENTACIÓN
FASE 12 — FUTURO (ZX80/81, +2/+3…)

El Director no pertenece a ninguna de estas fases: las coordina a todas.

3. Las técnicas de lexing/parsing

Cuando procesamos el fichero de origen existen varias maneras de enfocar el compilador o transpilador. En algunos lenguajes el parser debe mirar hacia adelante o hacia atrás entre muchos tokens, lo que implica disponer de todos ellos; en otros, como ZX BASIC, cada línea constituye una unidad completa (“LineNumber → sentencias separadas por :”), lo que permite estrategias mucho más ligeras.

3.1 Tokenizar todo el fichero: LexAll + ParseProgram

• Cómo funciona: el lexer produce la lista completa de tokens del fichero entero (incluye EOL por línea). El parser recorre esa lista y construye el AST global.
• Ventajas: diseño simple; el parser recorre una secuencia homogénea; lookahead sencillo.
• Inconvenientes: consume mucha RAM; listas grandes; GC costoso; hay que esperar a tener todos los tokens para empezar.

Variantes de “LexAll”

• Tokenizar en memoria: todos los tokens en una lista → muy rápido en PC; consume mucha RAM en máquinas limitadas.
• Tokenizar en disco: los tokens se guardan en un fichero intermedio → útil en PC; muy lento en microdrives del QL.

3.2 Tokenizar y parsear por líneas (técnica elegida)

• Cómo funciona: el Director lee cada línea; el lexer tokeniza esa línea; el parser procesa sentencias separadas por :; libera tokens y pasa a la siguiente línea.
• Ventajas: memoria mínima; velocidad muy alta en QL; una sola pasada; no requiere listas globales ni ficheros auxiliares.
• Inconvenientes: el parser trabaja por línea (no por programa). Lenguajes con sentencias multilínea no podrían usar este método, pero en ZX BASIC cada línea es una unidad completa, así que encaja perfectamente.

Como el objetivo final es ejecutar en QL real, usaremos la técnica por líneas. El lexer expone LexLine(texto, numLinea) y el parser expone ParseLine(tokens, numLinea). Esta técnica maximiza la velocidad y minimiza el uso de memoria.

Comparativa rápida

4. Flujo general del proceso (optimizado QL)

Inicio
   ↓  leer fichero .BAS línea a línea
Lexer (por línea)
   ↓  tokens de esa línea (LineNumber, ... , ":" para sentencias)
Parser (por línea)
   ↓  procesa sentencias separadas por ":" y libera tokens
Transformaciones / Emisión (fases posteriores)

Esta secuencia garantiza un procesamiento ordenado, con uso mínimo de memoria y arranque inmediato desde la primera línea.

5. Esqueleto del Director (seudocódigo)

El Director optimizado para su ejecución en el QL lee el fichero de origen línea a línea, llama a Lexer, Parser, etc., guarda lo que ha generado y pasa a la siguiente línea. Abajo se muestra un esquema básico; en el apéndice encontrarás la versión extendida con gestión de errores y opción verbose.

FUNCIÓN TranspilerDriver(rutaEntrada)
    Lexer.Preparar()
    Parser.Preparar()
    Semantico.Preparar()
    Transformador.Preparar()
    Emisor.Preparar()

    numeroLineaFisica ← 0
    PARA CADA lineaTexto EN leerLineas(rutaEntrada)
        numeroLineaFisica ← numeroLineaFisica + 1

        ListaTokens ← Lexer.Procesar(lineaTexto, numeroLineaFisica)
        AstLinea ← Parser.Procesar(ListaTokens, numeroLineaFisica)
        Semantico.RegistrarLinea(AstLinea)
        Semantico.VerificarReferenciaSaltos(AstLinea)
        AstTransformada ← Transformador.Aplicar(AstLinea, Politicas)
        Emisor.Emitir(AstTransformada)
    FIN PARA

    Semantico.VerificarSaltosPendientes()
    escribirConsola("Transpilación completada correctamente.")
FIN TranspilerDriver

6. Integración con las siguientes fases

• Fase 3 (Semántico): se aplicará línea a línea o al final de un primer pase completo.
• Fase 4 (Transformaciones ZX→SB): mapeo del charset y normalizaciones.
• Fase 5 (Generación SuperBasic): emisión del código destino.
• Fase 6 (Optimización): ajustes sobre el código resultante.

7. Próximo paso

En la siguiente entrada comenzaremos con el lexer (análisis léxico), usando la EBNF final y la estructura LineNumber → SimpleStatement { ":" SimpleStatement }.

En el modo verbose se mostrarán por pantalla todos los tokens emitidos por el lexer, lo que es útil para diagnósticos y muy informativo del proceso generado.

APÉNDICE: Director del proceso completo

Por completar, aquí añado el seudocódigo del director del proyecto más desarrollado, incluyendo control de errores y manejo de la opción verbose para salida de información adicional en pantalla:

// ==================================================================================
//  Director del Proceso (QL) — Seudo‑código con gestión de errores
//  • Procesamiento por líneas (memoria mínima)
//  • Manejo explícito de diagnósticos en TODAS las fases
//  • Política de error configurable: "AbortarAlPrimerError" o "AcumularYContinuar"
//  • Opción Verbose con salida en pantalla de información adicional
// ==================================================================================

TIPO PoliticaErrores = { AbortarAlPrimerError, AcumularYContinuar }

FUNCIÓN TranspilerDriver.Ejecutar(rutaEntrada, verbose, politicaErrores) → Booleano
    SI noExisteArchivo(rutaEntrada) ENTONCES
        escribirConsola("Error: no se encuentra el fichero de entrada.")
        RETORNAR FALSO
    FIN SI

    SI NO Lexer.Preparar(verbose) ENTONCES
        ReportarDiagnosticos("Lexer.Preparar", Lexer.Diagnostics)
        RETORNAR FALSO
    FIN SI
    SI NO Parser.Preparar(verbose) ENTONCES
        ReportarDiagnosticos("Parser.Preparar", Parser.Diagnostics)
        RETORNAR FALSO
    FIN SI
    SI NO Semantico.Preparar(verbose) ENTONCES
        ReportarDiagnosticos("Semantico.Preparar", Semantico.Diagnostics)
        RETORNAR FALSO
    FIN SI
    SI NO Transformador.Preparar(verbose) ENTONCES
        ReportarDiagnosticos("Transformador.Preparar", Transformador.Diagnostics)
        RETORNAR FALSO
    FIN SI
    SI NO Emisor.Preparar(verbose) ENTONCES
        ReportarDiagnosticos("Emisor.Preparar", Emisor.Diagnostics)
        RETORNAR FALSO
    FIN SI

    numeroLineaFisica ← 0
    huboErrores ← FALSO

    PARA CADA lineaTexto EN leerLineas(rutaEntrada)
        numeroLineaFisica ← numeroLineaFisica + 1

        INTENTAR
            ListaTokens ← Lexer.Procesar(lineaTexto, numeroLineaFisica)
        CAPTURAR ex
            Lexer.Diagnostics.Agregar(DiagFatal(ex, numeroLineaFisica))
        FIN

        SI noEstaVacio(Lexer.Diagnostics) ENTONCES
            ReportarDiagnosticos("Lexer (línea " + aCadena(numeroLineaFisica) + ")", Lexer.Diagnostics)
            huboErrores ← VERDADERO
            SI politicaErrores = AbortarAlPrimerError ENTONCES RETORNAR FALSO FIN SI
            CONTINUAR PARA
        FIN SI

        INTENTAR
            AstLinea ← Parser.Procesar(ListaTokens, numeroLineaFisica)
        CAPTURAR ex
            Parser.Diagnostics.Agregar(DiagFatal(ex, numeroLineaFisica))
        FIN

        SI noEstaVacio(Parser.Diagnostics) ENTONCES
            ReportarDiagnosticos("Parser (línea " + aCadena(numeroLineaFisica) + ")", Parser.Diagnostics)
            huboErrores ← VERDADERO
            SI politicaErrores = AbortarAlPrimerError ENTONCES RETORNAR FALSO FIN SI
            CONTINUAR PARA
        FIN SI

        INTENTAR
            Semantico.RegistrarLinea(AstLinea)
            Semantico.VerificarReferenciaSaltosParcial(AstLinea)
        CAPTURAR ex
            Semantico.Diagnostics.Agregar(DiagFatal(ex, numeroLineaFisica))
        FIN

        SI noEstaVacio(Semantico.Diagnostics) ENTONCES
            ReportarDiagnosticos("Semántico (línea " + aCadena(numeroLineaFisica) + ")", Semantico.Diagnostics)
            huboErrores ← VERDADERO
            SI politicaErrores = AbortarAlPrimerError ENTONCES RETORNAR FALSO FIN SI
            CONTINUAR PARA
        FIN SI

        INTENTAR
            AstTransformada ← Transformador.Aplicar(AstLinea, Politicas)
        CAPTURAR ex
            Transformador.Diagnostics.Agregar(DiagFatal(ex, numeroLineaFisica))
        FIN

        SI noEstaVacio(Transformador.Diagnostics) ENTONCES
            ReportarDiagnosticos("Transformador (línea " + aCadena(numeroLineaFisica) + ")", Transformador.Diagnostics)
            huboErrores ← VERDADERO
            SI politicaErrores = AbortarAlPrimerError ENTONCES RETORNAR FALSO FIN SI
            CONTINUAR PARA
        FIN SI

        INTENTAR
            Emisor.Emitir(AstTransformada)
        CAPTURAR ex
            Emisor.Diagnostics.Agregar(DiagFatal(ex, numeroLineaFisica))
        FIN

        SI noEstaVacio(Emisor.Diagnostics) ENTONCES
            ReportarDiagnosticos("Emisor (línea " + aCadena(numeroLineaFisica) + ")", Emisor.Diagnostics)
            huboErrores ← VERDADERO
            SI politicaErrores = AbortarAlPrimerError ENTONCES RETORNAR FALSO FIN SI
            CONTINUAR PARA
        FIN SI
    FIN PARA

    INTENTAR
        Semantico.VerificarSaltosPendientes()
        Semantico.VerificarBloquesPendientes()
    CAPTURAR ex
        Semantico.Diagnostics.Agregar(DiagFatal(ex, 0))
    FIN

    SI noEstaVacio(Semantico.Diagnostics) ENTONCES
        ReportarDiagnosticos("Semántico (verificación final)", Semantico.Diagnostics)
        huboErrores ← VERDADERO
        SI politicaErrores = AbortarAlPrimerError ENTONCES RETORNAR FALSO FIN SI
    FIN SI

    SI huboErrores ENTONCES
        escribirConsola("Transpilación finalizada con incidencias.")
        RETORNAR FALSO
    SINO
        escribirConsola("Transpilación completada correctamente.")
        RETORNAR VERDADERO
    FIN SI
FIN FUNCIÓN

PROCEDIMIENTO ReportarDiagnosticos(etapa, listaDiag)
    escribirConsola("=== Errores en " + etapa + " ===")
    PARA CADA diag EN listaDiag
        escribirConsola(diag.aTexto())
    FIN PARA
FIN PROCEDIMIENTO

FUNCIÓN DiagFatal(excepcion, linea) → Diagnostico
    diag ← nuevo Diagnostico
    diag.Linea ← linea
    diag.Columna ← 1
    diag.Mensaje ← "Fatal: " + excepcion.mensaje
    RETORNAR diag
FIN FUNCIÓN

Índice de entradas del conversor

Modificado el 12/03/2026, ampliaciones en color rojo

Gramática del ZX BASIC del Spectrum 48K

Esta entrada ofrece un resumen estructurado de la gramática del ZX BASIC del Sinclair ZX Spectrum 48K, basado en las referencias originales del manual oficial del Spectrum y las versiones digitalizadas del manual en español. Primero se presenta una versión ligera y, después, la definición formal completa.

• BNF/EBNF práctica, apta para implementar (recursive descent o LL(1) con pequeñas adaptaciones).
• Las restricciones del hardware (p. ej. rango de números de línea) se indican en comentarios.
• Se prioriza claridad en la introducción; los detalles formales aparecen en el BNF completo final.

NOTA IMPORTANTE: heredado de los ZX80/81 con solo 1 KB disponible, para ahorrar memoria todas las palabras clave se almacenan internamente como tokens de 1 byte. Por tanto, toda sentencia debe comenzar obligatoriamente por un token de palabra clave. No puede comenzar por un identificador. LET es obligatorio siempre. REM solo se reconoce si es exactamente REM.

Estos ajustes son mínimos pero críticos para definir correctamente la gramática y la generación de tokens.

1. Estructura de un programa

Un programa en ZX BASIC está compuesto por líneas numeradas:

<linea> ::= <numero> <espacio> <instruccion>

• Los números de línea van de 1 a 9999.
• Una línea puede contener una o varias instrucciones separadas por :.

2. Tipos de datos

2.1 Tipos básicos

• Números: coma flotante de 40 bits.
• Cadenas: delimitadas por comillas ("texto").
• No existen enteros ni booleanos como tipos nativos; la lógica usa 0 para falso y <>0 para cierto.

2.2 Nombres de variables

<var_num> ::= <letra> [ <letra_o_digito> ]
<var_str> ::= <letra> [ <letra_o_digito> ] "$"
<var_array> ::= <var> "(" <lista_expresiones> ")"

• Las variables numéricas y de cadena con el mismo nombre son distintas.
• Las matrices pueden ser numéricas o de cadena.

3. Expresiones

3.1 Expresiones numéricas

Precedencia de operadores (de mayor a menor):

1. Unario: -
2. Potencia: ^
3. Multiplicación / División: * /
4. Suma / Resta: + -
5. Relacionales: =, <, >, <=, >=, <>
6. Lógicos: AND, OR, NOT

Fuentes: capítulos 3, 7 y 13 del manual.

3.2 Expresiones de cadena

• Concatenación: "A" + "B".
• Slicing: A$(n TO m).
• Longitud: LEN A$.

Fuente: capítulo 8 del manual.

4. Sentencias

4.1 Asignación

<asignacion> ::= LET <var> = <expresion>

LET es obligatorio en el Spectrum 48K (no puede omitirse).

4.2 Entrada y salida

• PRINT
• INPUT
• CLS
• TAB(n), AT y,x

Fuente: capítulos 2 y 15 del manual.

5. Control de flujo

5.1 IF

IF <expresión> THEN <instrucciones>

Ejecuta todas las instrucciones (separadas por :) hasta fin de línea. No existe ELSE en el ZX Spectrum 48K.

5.2 Bucles FOR

FOR <var> = <expr> TO <expr> [STEP <expr>]
...
NEXT <var>

Fuente: capítulo 4 del manual.

5.3 Subrutinas

GOSUB número
RETURN

Fuente: capítulo 5 del manual.

5.4 Saltos

• GO TO
• STOP
• CONTINUE

6. Datos

READ <lista_variables>
DATA <lista_constantes>
RESTORE [número]

Fuente: capítulo 6 del manual.

7. Comentarios

En ZX Spectrum 48K, la sentencia REM admite exactamente dos formas:

• Comentario vacío: REM seguido inmediatamente de fin de línea.
• Comentario con contenido: REM seguido de un ESPACIO y, a continuación, cualquier número de caracteres (incluidos espacios) hasta fin de línea.

Ejemplos válidos:

10 REM
20 REM Hola mundo
30 REM  Más espacios al inicio del comentario

Ejemplos inválidos:

40 REMHola     ; falta el espacio tras REM
50 REMHola ; tabulación inmediata tras REM (no permitido)

EBNF:

ESPACIO      = " ";
EOL          = "\n";
anyCharacter = ? cualquier carácter Unicode ? ;

remStmt =
      "REM"
    | "REM" , ESPACIO , { anyCharacter } ;

8. Funciones incorporadas

Matemáticas

ABS, INT, SGN, SIN, COS, TAN, ASN, ACS, ATN, SQR, EXP, LN, PI …

Cadenas

LEN, STR$, VAL, CHR$, CODE

Sistema

PEEK, POKE, USR, IN, OUT, RND, RANDOMIZE

Fuente: capítulos 9, 10, 11, 14 y 23 del manual.

9. Arrays

DIM A(10)
DIM N$(5)

• Índices desde 1 hasta el tamaño declarado (arrays base 1).
• Acceso: A(1), A(5), N$(1)…

10. Gráficos

• PLOT x,y
• DRAW dx,dy
• CIRCLE x,y,r
• POINT x,y

Fuente: capítulo 17 del manual.

11. Colores

• INK n
• PAPER n
• FLASH n
• BRIGHT n
• INVERSE n
• OVER n
• BORDER n

Fuente: capítulo 16 del manual.

12. Sonido

BEEP duracion, tono

Fuente: capítulo 19 del manual.

13. Cinta y ficheros

• SAVE
• LOAD
• MERGE
• VERIFY

Fuente: capítulo 20 del manual.

14. Gramática mínima para transpiladores

<program> ::= { <line> }

<line> ::= <number> <Statement>

<Statement> ::= <SimpleStatement> { ":" <SimpleStatement> }

<SimpleStatement> ::= <assign>
                     | PRINT <print_list>
                     | INPUT <var_list>
                     | IF <expr> THEN <Statement>
                     | FOR <assign> TO <expr> ["STEP" <expr>]
                     | NEXT <var>
                     | GOSUB <number>
                     | RETURN
                     | GO TO <number>
                     | READ <var_list>
                     | DATA <const_list>
                     | DIM <dim_list>
                     | PLOT | DRAW | CIRCLE | POINT | ...

15. BNF/EBNF del ZX BASIC del Spectrum 48K (versión corregida)

1) Léxico

letter        = "A".."Z" | "a".."z"
digit         = "0".."9"
nonZeroDigit  = "1".."9"
alnum         = letter | digit

numVar        = letter , [ alnum ]
strVar        = letter , [ alnum ] , "$"
var           = numVar | strVar

intLiteral    = digit , { digit }
fractPart     = "." , { digit }
expPart       = ("E" | "e") , [ "+" | "-" ] , digit , { digit }

numLiteral    = intLiteral , [ fractPart ] , [ expPart ]
              | fractPart , [ expPart ]

ESPACIO      = " "
EOL          = "\n"
anyCharacter = ? cualquier carácter Unicode ?

strLiteral    = '"' , { anyCharacter } , '"'


; REM solo se reconoce como palabra clave si el token es exactamente "REM".
; Un identificador NO puede iniciar una sentencia.

2) Estructura del programa

program       = { line }

line          = lineNumber , Statement
lineNumber    = LineNumberToken
LineNumberToken = nonZeroDigit , [ digit ] , [ digit ] , [ digit ]
(* Rango efectivo: 1..9999; token específico generado por el lexer *)

3) Statement y SimpleStatement

Statement     = SimpleStatement , { ":" , SimpleStatement }

; SimpleStatement debe comenzar por token de palabra reservada

SimpleStatement =
                   letStmt
                 | printStmt
                 | inputStmt
                 | ifStmt
                 | forStmt
                 | nextStmt
                 | gotoStmt
                 | gosubStmt
                 | returnStmt
                 | stopStmt
                 | continueStmt
                 | readStmt
                 | dataStmt
                 | restoreStmt
                 | dimStmt
                 | clsStmt
                 | graphicStmt
                 | colorStmt
                 | soundStmt
                 | tapeStmt
                 | remStmt

4) Expresiones

expr          = logicOr
logicOr       = logicAnd , { "OR" , logicAnd }
logicAnd      = relation , { "AND" , relation }

relation      = arithExpr , [ relOp , arithExpr ]
relOp         = "=" | "<>" | "<" | ">" | "<=" | ">="

arithExpr     = term , { ("+" | "-") , term }
term          = power , { ("*" | "/") , power }
power         = unary , { "^" , unary }

unary         = [ "-" | "NOT" ] , primary

primary       = numLiteral
              | strLiteral
              | varRef
              | funcCall
              | "(" , expr , ")"

5) Variables y arrays (base 1)

varRef        = arrayRef | var

arrayRef      = ( numVar | strVar ) ,
                "(" , indexExpr , { "," , indexExpr } , ")"

indexExpr     = expr

6) Funciones

funcCall      = funcNum | funcStr | sysFunc

funcNum       = ("ABS" | "INT" | "SGN" | "SIN" | "COS" | "TAN"
                | "ASN" | "ACS" | "ATN" | "SQR" | "EXP" | "LN"
                | "VAL" | "PI")
                "(" , [ expr ] , ")"

funcStr       = "LEN" "(" , ( strVar | strLiteral ) , ")"
              | "STR$" "(" , expr , ")"
              | "CHR$" "(" , expr , ")"

sysFunc       = "PEEK" "(" , expr , ")"
              | "USR"  "(" , expr , ")"
              | "CODE" "(" , (strVar | strLiteral) , ")"

7) Sentencias (detalle)

remStmt   = "REM"
          | "REM" , ESPACIO , { anyCharacter }
 

letStmt   = "LET" , ( varRef | var ) , "=" , expr

printStmt = "PRINT" , [ printList ]
printList = printItem , { ("," | ";") , printItem }
printItem = expr
          | "TAB" "(" , expr , ")"
          | "AT" expr "," expr

inputStmt = "INPUT" , varList
varList   = varRef , { "," , varRef }

ifStmt    = "IF" , expr , "THEN" , Statement

forStmt   = "FOR" , numVar , "=" , expr , "TO" , expr , [ "STEP" , expr ]
nextStmt  = "NEXT" , [ numVar ]

gotoStmt  = ("GOTO" | "GO TO") , lineNumber
gosubStmt = ("GOSUB" | "GO SUB") , lineNumber
returnStmt= "RETURN"

stopStmt  = "STOP"
continueStmt = "CONTINUE"

readStmt  = "READ" , varList
dataStmt  = "DATA" , constList
constList = constItem , { "," , constItem }
constItem = numLiteral | strLiteral

restoreStmt = "RESTORE" , [ lineNumber ]

dimStmt   = "DIM" , dimList
dimList   = dimItem , { "," , dimItem }
dimItem   = ( numVar | strVar ) , "(" , sizeExpr , { "," , sizeExpr } , ")"
sizeExpr  = expr

clsStmt   = "CLS"

graphicStmt = plotStmt | drawStmt | circleStmt | pointStmt
plotStmt  = "PLOT" , expr , "," , expr
drawStmt  = "DRAW" , expr , "," , expr
circleStmt= "CIRCLE" , expr , "," , expr , "," , expr
pointStmt = "POINT" , expr , "," , expr

colorStmt = ("INK" | "PAPER" | "FLASH" | "BRIGHT" | "INVERSE" | "OVER" | "BORDER") , expr

soundStmt = "BEEP" , expr , "," , expr

tapeStmt  = ("SAVE" | "LOAD" | "VERIFY" | "MERGE") , strLiteral

16. Referencias

• Manual canónico (World of Spectrum) — Índice completo del ZX Spectrum BASIC Programming Manual (Sinclair/Amstrad). https://worldofspectrum.org/ZXBasicManual/
• World of Spectrum — Capítulo 13: Conditions — Operadores lógicos y prioridad (AND/OR/NOT, relacionales). https://worldofspectrum.org/ZXBasicManual/zxmanchap13.html
• Introducción Sinclair (Statement LET) — Especifica que en 48K LET no puede omitirse. https://worldofspectrum.org/ZXSpectrumIntroduction/chapter_five.html
• Manual de Investrónica (español) — Edición en HTML con capítulos de cadenas, matrices, gráficos y colores (consulta rápida). https://manuales.speccy.org/basic_gomas/