Jupiter Ace Forth: Forth Debugger

[Elurdio]

Último mensaje de la página anterior:

Veo que DEBUG utiliza la base en curso cuando muestra la pantalla de depuración. Si una palabra la cambia por otra, pues DEBUG usará esa otra, lo cual puede ser un problema si la nueva base es menor que 10.

Esto es debido a que DEBUG espera que los números que imprime en la pantalla del depurador tengan como máximo 6 dígitos contando el posible signo menos. Si, por ejemplo, se activa base 2 entonces la pantalla de depuración se podría desbaratar.

Voy a tener que forzar que la pantalla de depuración use una base igual o mayor que 10. No sé si ponerla fija a 10 o que se pueda escoger también base 16 mediante un comando. Esta base solo será válida al mostrarse la pantalla de depuración, la palabra que se depura (y la pantalla original) seguirán usando la que sea que usen.

Además, haciendo pruebas sobre el tema, me he percatado que la palabra ABORT no se depura bien.

Mira que hace poco probé a depurar todas y cada unas de las 142 palabras del diccionario Forth, pero por lo visto me salté ABORT...

Así pues quedan dos temas pendientes:

• Fijar una base de trabajo del depurador (10 o mayor)
• Arreglar el BUG con la palabra ABORT

EDIT:(12:40) También falla QUIT. Por lo visto no probé las dos últimas palabras de VLIST: ABORT y QUIT.

[Elurdio]

QUIT y ABORT están muy relacionadas. Son las únicas palabras que llaman al Main Execution Loop del Ace Forth.

Precisamente ahí radica el problema, en llamar al MEL estando la depuración en marcha.

Creo que la mejor manera de solucionar el problema es interceptar el inicio del Main Execution Loop.

Así, cuando se ejecute QUIT/ABORT harán lo que tienen que hacer pero en cuanto salten al MEL se interceptará y se podrá hacer que se detenga inmediatamente DEBUG -> Quitar todas las interceptaciones, restaurar el Secuenciador Original y entonces proceder a ejecutar el Main Execution Loop.

[Elurdio]

Ya he corregido el BUG con QUIT y ABORT y también he fijado la base numérica a 10 cuando se muestra la pantalla de depuración independientemente del valor que tenga en ese momento.

He actualizado en el primer post del hilo DEBUG.TZX y en los posts correspondientes el código fuente de la palabra DEBUG y de la rutina maestra en c.m. que carga DEBUG.

Espero que con esto ya pueda dar por finalizado el Forth Debuger.

[Elurdio]

Otro BUG

Este lo he visto porque se ha cumplido una tremenda casualidad. Tiene que ver con tamaño del diccionario y/o con el tamaño de la pila. Solo que la pila cambie unos cuantos bytes de tamaño o el diccionario varía un poquito, ya no se da. Aún tengo que determinar con precisión las condicioes que lo provocan. De momento parece ser que el final del diccionario (y por ende la pila, pues siempre va después del diccionario) han de estar por encima de $8000.

Pero si se da, el BUG es grave, puede colgar el Jupiter Ace. Los síntomas que he visto es que se muestra más números de los que hay en la pila y la palabra a ejecutar en al pantalla de depuración es un nombre sin sentido, un nombre basura. Si escojo el comando "Abort" (Abo) se salva la situación. Otros comando me cuelgan el JA.

En fin, cuando pueda me lo miro a fondo.

[Elurdio]

El BUG está relacionado con la dirección que ocupa el tope de la pila. Da igual como se alcance, si aumentando el tamaño del diccionario o aumentadon el tamaño de la pila o por ambos métodos. Si se llega a valor "crítico" se produce el error.

Este valor es $8AFB, a veces 1+ o 1-.

Lo de verse valores de la pila inexistentes NO sucede siempre. Lo que sí acontece es que el nombre de la palabra actual a ejecutar en la pantalla del depurador es "basura". Mirando con el Z80 debuger se ve que el valor anotado por DEBUG para el CFA de la palabra actual está corrompido y nada tiene que ver con el real.

EDIT(13:17): La cosa NO es tan poco probable como creía. En realidad sucede siempre que el Low bytes es $FA o cercano y el High Byte es $8A, $89, $87, ... o creciendo: $8A, $8C, $8D, $8D.

Además, sucede aunque estemos por debajo del $8000.

EDIT(23:31): El fallo no está en la rutina maestra en c.m. Es anterior, en alguna palabra que ejecuta DEBUG antes de instalar dicha rutina. Ya la he localizado, es la palabra VARS>STORE. Vamos a ver que narices pasa.... Desgraciadamente NO puedo usar DEBUG en las condiciones que dan el BUG para rastrear VARS>STORE, pues se produce el BUG. Hay que hacerlo a mano.

[Elurdio]

Madre mía, seré reburro

El fallo está en mi versión en c.m. de la palabra 2DROP. Palabra que uso en multitud de palabras (entre ellas VARS>STORE) y que está MAL programada. Hace ya casi 8 meses que la programé y la incorporé a mi Diccionario General. Seguro que ha hecho más estropicios por ahí pero no se han manifestado aún...

El fallo es GARRAFAL:

LD    HL,$3C3B
DEC   (HL)
DEC   (HL)
DEC   (HL)
DEC   (HL)
JP    (IY)

$3C3B es la dirección en memoria dónde se almacena la dirección del tope de la pila como un entero de dos bytes. 2DROP equivale a restarle 4 al número allí alamacenado y tal como lo he hecho he restado cuatro al Low Byte de dicho número sin considerar el High byte...

Ahora voy a tener que revisar todos mis programas a vers is usan 2DROP y si usan esta mierdoversión pues a actualizarlo.... que rollo!!

[Elurdio]

Tras más de dos semanas sin tocar el Ace Forth, se me ocurrió ejectuar DEBUG con un par de casos que ya había probado (pues en su día probé todas y cada una de las 142 palabras del Ace Forth) y la cosa no ha ido muy bien.

Concretamente he aplicado DEBUG a las plabras LIST y EDIT. No son palabras que se espera uno encontrar dentro de la definición de otra palabra, pero es posible.

Las pruebas funcionan bien excepto cuando la palabra que se lista o edita contiene un LITERAL (un número). Entonces no va bien (Step/Over).

Tienen en común lo que lo causa (la presencia de un número en la definición) pero el resultado es diferente.

Con LIST se muestra al depurar una palabra con el nombre "basura" ~#(w a cada número que encuentra. Pero hace el listado correctamente.

Con EDIT la cosa es peor, pues se produce un ERROR 9 en cuanto encuentra un número (intento de escritura en el input búfer).

Solo lo comento, pues NO creo que lo arregle, dado que ya estoy muy desconectado del tema.

[Elurdio]

Le acabo de echar un vistazo al problema.

En primer lugar, como me esperaba, el fallo en EDIT viene por el LIST que ejecuta internamente EDIT como paso previo a la edición. Luego el problema viene de LIST.

Ahora bien, no me veo con fuerzas para depurar el problema usando el debugger del Z80, pues la palabra LIST es una de las más enrevesadas que tiene Ace Forth. Realmente mareante....

El fallo de LIST no es muy grave, muestra un nombre basura a cada número que encuentra. NO debería hacerlo, pero se puede sobrellevar.

En cuanto al EDIT el fallo es grave, se produce un error y se aborta la depuración. Así que, de momento las palabras de usuario que contengan EDIT en su definición (lo cual intuyo que es "muy raro") NO se pueden depurar si dicho EDIT se ejecuta. Por lo que si durante una depuración nos aparece una palabra que sabemos contiene un EDIT se debería usar Over, nunca Step con dicha palabra.

[Elurdio]

Buscando un atajo para no tener que depurar toda la palabra LIST con el Z80 debugger, he localizado la palabra "headerless" que escupe como su inexistente nombre la basura: ~#(w.

En principio NO se puede, a partir de la basura que escupe el programa deducir cual es la headerless que lo hace, salvo que tengamos un listado con todos los CFAs de palabras headerless de la ROM e ir probando cada uno con una palabra (que tengo definida para otros fines) que imprime el nombre de una palabra de la ROM, y ver si coincide con nuestra basura en concreto.

Pero he tenido suerte. Me sonaba ese nombre-basura de haberlo visto antes. Y sí, lo ví aquí (hace más de un mes). Esta pista ya me ha permitido localizarlo:

La palabra en cuestión es la que tiene CFA=181B.

Es una palabra headerless que se usa como truco para que la rutina en c.m. que imprime el número en HL como entero con signo en pantalla (empieza en $180E) pueda seguir ejecutando las palabras Forth que siguen a quién la llamó.

Esta rutina en $180E solo es llamada por LIST cuando imprime un número entero (por ende por EDIT también) y por F. cuando imprime el exponente de un número decimal (si no tiene exponente NO la llama).

He probado cargando en la pila un decimal con exponente y haciendo DEBUG F. y aparece el ~#(w.

La cosa ahora ya es mucho más accesible a mis "fuerzas" actuales. Creo que ya podré solucionar el asunto. En cuanto lo tenga hecho, pongo la nueva versión de DEBUG en el primer post con la correspondiente nota de edición.

NOTA: Lo extraño es que esta ya mañana sospeché de esta rutina en $180E y puse un breakpoint en el debugger del Z80 y al ejecutar un LIST de una palabra con EDIT, escupía el nombre-basura en el depurador PERO NO SE INTERRUMPIA la ejecución por lo que la descarté como rutina sospechosa. Ahora, en cambio, veo que F. sí que se interrumpe en iguales circunstancias.

O sea, durante el depurado de un decimal con exponente F. llama a $180E que a su vez ejecuta la Headerless ~#(w pero en cambio durante el depurado deL LIST de una palabra con EDIT, aunque se informa que se va a ejecutar ~#(w, NO lo hace a través de $180E. O lo hace por llamada directa (que no localizo en el desensamblado de la ROM) o es otra cosa que casualmente escupe el mismo nombre basura, pero siendo ambos casos debidos a la impresión de un entero en pantalla, lo dudo mucho ... RARO, MUY RARO...

EDIT:(ahora mismo) He puesto un breakpoint en $181D, que es dónde empieza la ejecución en c.m. de la headerless ~#(w y he verificado que es la que ejecuta LIST también. Lo que tengo que aclarar es como llega aquí sin llamar a ~#(w...

[Elurdio]

LIST utiliza la rutina $180E pero entra más adelante, por $1815, de ahí que NO se detuviera con el breakpoint en $180E.

Hay otra palabra ROM que entra también por este punto con un CALL $1815. Es una headerless que se usa durante la creación de comentarios en las definiciones con paréntesis y solo llama a $1815 si falta el paréntesis final, el que cierra el comentrio. He probado usando DEBUG con un comentario sin paréntesis final durante la definición de una palabra y no me ha dado ningún problema. Así que no voy a considerar este caso concreto.

Ahora caigo que la rutina $180E es una cosa y la rutina $1815 es otra.

La $180E utiliza la $1815 que es una rutina más general. En concreto $1815 espera en el registro DE el CFA de la palabra ROM a ejecutar como un EXECUTE "interno". Como la $180E está antes en memoria, carga DE con el CFA de "." (punto, la palabra que imprime el top de la pila de datos) y continúa con $1815 que viene justo a continuación. El conjunto equivale a un EXECUTE "interno" de "." con el número a imprimir en HL.

En el desensamblado en inglés de la ROM del Ace Forth parece que dan por hecho que es todo una misma rutina y que DE vale el CFA de "." cuando NO es así, pues la otra palabra que usa la rutina $1815 pone en DE el CFA de RETYPE antes de llamarla. Aunque también indican que $1815 se llama dos veces como rutina independiente...

Así pues la rutina en $1815 sirve para ejecutar cualquier palabra ROM y luego prosigue con Forth. Solo necesita el valor del CFA de la palabra a Ejecutar en DE. Es un EXECUTE "interno" generalizado.

Curiosamente solo se utiliza dos veces en total, una para ejecutar "." y la otra para ejecutare RETYPE. Pero se podría usar para cualquier otra palabra. Así que la añadadiré al listado de rutinas en c.m. aprovechables del final del hilo TUTORIALES aquí . La $180E es un caso particular para ejecutar ".", pero esta rutina $1815 es general.

[Elurdio]

Tras el paréntesis de dos semanas desconectado del Ace Forth y que sobre como traté el tema de los EXECUTE externos/internos apenas comenté nada en el foro ni en los comentarios del fuente de la rutina en c.m. del DEBUG, pues me he visto bastante perdido.

El caso que nos atañe ahora del LIST y F. no es más que otro caso de EXECUTE interno. Pero un caso que se me escapó y la rutian en c.m. no lo contempla.

Digamos que hay dos casos de EXECUTE interno:

1. El que finaliza la palabra. Es cuando se hace un JP $4BF con DE=CFA a ejecutar.
2. El que la tras él, la ejecución continúa. Es cuando se utiliza el CALL $1815 con DE=CFA a ejecutar.

El caso que contemplé es el primero (tipo "a"). Los EXECUTE internos tipo "a" siempre terminan la ejecución de la palabra en curso. Si hubier más código después de él, pues NO se ejecutaría, es como si estuviera de adorno.

En cambio, el EXECUTE interno tipo "b", tras terminar prosigue con el código que viene a continuación. Este es el caso que NO contemplé y es justo el que utilizan tanto LIST como F. durante su ejecución.

Todo esto lo he comprobado con unos ejemplos sencillos que me he hecho en c.m. probando ambos tipos de EXECUTE internos.

El problema parece ser (no lo he comprobado del todo aún) que tras ejecutarse un EXECUTE interno (sea del tipo que sea), se da por terminado cualquier "Over" que hubiera activo. En el caso del tipo "a" como se finaliza la palabra pues no pasa nada pero si era tipo "b" esto es un problema pues la palabra que lo contiene sigue ejecutándose pero el "Over" ahora está inactivo por lo que si se ejecuta cualquier otra palabra se mostrará, que es lo que nos pasa en LIST y F. con la palabra headerless ~#(w, que se muestra cuando NO debería (debería seguir activo el "Over").

[Elurdio]

···
El problema parece ser (no lo he comprobado del todo aún) que tras ejecutarse un EXECUTE interno (sea del tipo que sea), se da por terminado cualquier "Over" que hubiera activo.···

Lo que realmente sucede es que los EXECUTE están al mismo "nivel" (desde el punto de vista de CONTADOR) que la palabra que los contiene, por lo que tras ejecutarse la palabra que "EXECUTA", CONTADOR vale lo mismo que tenía cuando se inició el "Over" y por tanto, mi sistema de detección de final de "Over" lo da por terminado erróneamente.

Esto sucede si el "Over" se activó al depurarse la palabra que contiene el EXECUTE (interno o externo). Si se activó en una palabra madre superior (a un "nivel" superior), todo va bien.

Como hasta ahora todos los execute internos eran de los que teminan la palabra (tipo "a"), no había problema. Pero con los tipo "b" pasa lo que hemos visto.

La solución NO pasa por sumar o restar uno a CONTADOR, pues no es un problema de descuento del mismo, es un problema que el método que uso para detectar el final de un "Over" NO funciona si hay un EXECUTE interno tipo "b". (*)

Me temo que voy a tener que hacer un Parche más para tratar este caso. Tengo que detectar si el final de un "Over" corresponde a este tipo "b" y si es así, NO desactivarlo.

(*) En realidad tampoco funciona si es tipo "a", pero como coincide con el final de palabra (pues él mismo la termina), no se nota el problema.

[Elurdio]

De momento he solucionado lo del LIST/F. que usaban el EXECUTE interno tipo "b" (rutina $1815).

De las diferentes soluciones que he intentado la que ha funcionado ha resultado la más sencilla, pues no he tenido que interceptar nada. Solo añadir una comprobación más además de la EXECUTE interna/externa que ya había. (*)

Ahora el depurado de EDIT ya no da error, pues se producía por el LIST que utiliza EDIT. Pero la cosa no va bien del todo, pues al depurarse EDIT me muestra un RETYPE antes de dejarme editar y un LINE justo al terminar de Editar. Todo va bien, pero NO deberían mostrarse esas dos palabras que EDIT utiliza internamente.

No actualizo aún el DEBUG.TZX pues me falta también ver posibles BUGs que pueda causar este arreglo en los casos que ya funcionaba todo bien.

(*) Aunque es ese tipo de comprobaciones que pueden fallar "por casualidad". Se base en comprobar que en la segunda posición del Rstack hay un valor determinado (concretamente $181B). Pero claro, puede darse la casualidad (aunque creo que es muy, pero que muy improbable) que haya allí precisamente ese valor por un motivo totalmente distinto del EXECUTE interno tipo "b"...

El caso que me daba miedo era el DEBUG de una palabra que contuviera un bucle DO/LOOP o similar. Si el índice estuviera en la 2ª posición del Rstack y pasara por ese valor tendríamos un problema y además gordo, pues es una situación no demasiado improbable. Pero como estamos ejecutando DEBUG, el índice como máximo puede estar en la 3ª posición (o mayor), nunca en la 2ª. Así que me quedo tranquilo.

Y más de lo mismo con >R, mínimo 3ª posición, etc.

[Elurdio]

Mirando en el desensamblado de la ROM la palabra EDIT para ver la causa del fallo de mostrar RETYPE y LINE, me acabo de dar cuenta que la solución que he dado para el EXECUTE tipo "b" es solo una solución "ad hoc" para el caso de LIST y F. que de hecho son las únicas palabras que lo usan directamente.

Mi solución solo evita que al ejecutarse un EXECUTE interno tipo "b" se imprima el pseudonombre de la palabra headerless ~#(w pero no evita la otra consecuencia de este EXECUTE, a saber, que DESACTIVA el "Over" pero se sigue ejecutando la palabra.

En el caso de LIST y F. no es un problema, pues después de este EXECUTE no llaman a ninguna palabra Forth desde c.m. ni hacen nada que pudiera dar problemas por estar el "Over" desactivado.

Pero EDIT, después de ejecutar internamente el LIST (que ha utilizado el EXECUTE interno tipo "b" y por ende ha desactivado el "Over") sí que ejecuta una llamada a Forth desde c.m. y al no estar el "Over" activo pues se depuran sus comandos, que no son otros que RETYPE y LINE.

Podría hacer otra comprobación solo para el caso concreto de EDIT y reactivar el "Over" en el momento oportuno....

Pero lo interesante es resolver el problema en general, pues el EXECUTE interno tipo "b" aunque Ace Forth solo lo utiliza en estos dos casos (LIST y F.) puede ser utilizado por cualquier usuario en sus programas en c.m. y esto requiere una solución general a la desactivación del "Over".

[Elurdio]

He quitado el comprobador "ad hoc" y ahora cuando detecto que se ha ejecutado un EXECUTE interno tipo "b" activo de nuevo el "Over".

El problema con la headerless ~#(w queda también resuelto de este modo, pero EDIT me sigue mostrando el RETYPE y el LINE.

Parece ser que el problema está en la palabra CORRECTOR:

CORRECTOR -> Palabra Forth que corrige CONTADOR en función del siguiente criterio:
(Así detectamos los saltos)
Si CONTADOR > CONTOLD y SP_NEW >= SP_OLD -> Restamos uno a CONTADOR

Me he hecho unas palabras en c.m. que hacen lo mismo (una chorrada) pero una usa el CALL $1815 seguido de una llamada a Forth desde c.m. y la otra lo hace sin usar el CALL $1815, solo con la llamada a Forth desde c.m.

Rastreandolas con el debugger del Z80 veo que el problema en la que tiene el CALL es que el CORRECTOR resta uno a CONTADOR cuando NO debería hacerlo.

Algo del EXECTUTE interno tipo "b" hace que se haga la resta. Tiene que ver con los valores de SP_NEW y SP_OLD que hace que detecte erróneamente que se ha producido un SALTO cuando NO es así.

No sé dónde puse que EXECUTE era mi "pesadilla" porque no cumple con el criterio de final de "Over" que utilizo. Ahora encima resulta que también interfiere con el criterio de detección de saltos... una PESADILLA al cuadrado!!

[gflorez]

Gracias Elurdio. Aunque esto parezca un monólogo, el tuyo, tengo planeado darle una oportunidad al Forth, primero siguiendo tu enciclopedia con el simulador de ACE, y luego aplicar lo aprendido al Enterprise.

Gran trabajo.

[Elurdio]

Gracias Elurdio. Aunque esto parezca un monólogo, el tuyo, tengo planeado darle una oportunidad al Forth, primero siguiendo tu enciclopedia con el simulador de ACE, y luego aplicar lo aprendido al Enterprise.

Gran trabajo.

Me alegra saber que esto no es solo mi "diario/apuntes" de mi trabajo en Ace Forth.

Como ya he comentado, este foro es donde único queda constancia de mis averiguaciones Ace Forthianas. Cuando retomo un tema que hace un tiempo que dejé aparcado, me sirvo de ellos como recordatorio y refresco del mismo. Bueno, estos posts y los comentarios en los fuentes.