Jupiter Ace Forth: Forth Debugger

[Elurdio]

Último mensaje de la página anterior:

Bug (pendiente de Solucionar)
Afecta a las palabras de Usuario en c.m. tipo primitivas -> CF=PFA que llaman a palabras Forth desde c.m.:
Problema: Muestran las palabras Forth a las que llaman tanto si se hace "Step" como "Over". NO deberían mostrarse en ningún caso:
···.

He rastreado un DEBUG de una palabra de este tipo con el depurador del Z80 y la cosa pinta fea. A falta de estudiarlo más a fondo, todo parece indicar que el método que usa el Ace Forth para llamar una palabra Forth desde c.m. (ver aquí) hace que se descuente CONTADOR por defecto (o sea, cuenta uno menos de lo que debería contar).

Este descuento a la baja hace que el "Over" automático que se impone a la palabra por ser una primitiva en c.m. se desactiva (se da por terminado, pues se cumple la condición necesaria, cuando NO debería cumplirse aún) en cuanto la palabra ejecuta la llamada al Forth desde su c.m.

Tengo una idea de una posible solución, pero como no funcione... feo, muy feo!

[Elurdio]

No hay mal que por bien no venga. Intentando solucionar el BUG anterior, que no es más que un caso que no contemplé de WP puesto en Rstack "fuera" del Secuenciador -> CONTADOR se descuenta.

La cosa se ha complicado, y ahondando más en la posible solución del mismo, acabo de detectar otro BUG por el estilo: Otro descuento de CONTADOR, ahora por WP quitado de Rstack "fuera" del Secuenciador.

Este segundo caso, afecta a muchísimas palabras del Ace Forth pero solo cuando se ejecutan en modo compilación y que NO había testeado aún (He tenido suerte: He detectado el BUG antes que se produjera)

Sí que probé un caso, el de ASCII y lo solucioné con un parche "ad hoc" interceptándola parcialmente. Pero ASCII es una palabra más rara que un bocadillo de garbanzos. Así que no me extrañó tenerla que tratar aparte. Ahora veo que la cosa es mucho más general, por lo que tendré que hacer un parche general (que espero sea válido para ASCII también).

La solución del primer BUG pasa por solucionar también el segundo, así que mataré dos pájaros de un tiro.

Lo único que me preocupa es que solucionando esto casque otra cosa.... el pan nuestro de cada día.

Todo esto es porque al plantearme hacer DEBUG, he partido de un supuesto general del funcionamiento del Ace Forth y luego, una vez implementado, me voy encontrando, mientras lo uso, con toda clase de excepciones y cosas que no sabía. Quizás más me hubiera valido estudiarme a fondo el Desensamblado del Ace Forth y conocer de antemano todos los pormenores y, solo entonces, haberme puesto manos a la obra con el DEBUG.

[Elurdio]

Bueno, ya he solucionado los dos BUGs y además, como tenía esperanzas de que así fuera, el caso Particular del ASCII se soluciona con este caso más general. Así que ahora DEBUG ya NO intercepta parcialmente la ROM de ASCII. (*).

El problema con las llamadas a palabras Forth desde c.m. es doble. Al hacer la llamada CONTADOR se descuenta de uno (le falta uno) y al hacer la vuelta al c.m. CONTADOR se descuenta de uno (le sobra uno).

Recordemos que la llamada se hace con CALL $04B9 y el retorno a c.m. se hace poniendo como último CA de palabra Forth a ejecutar $1A0E

El $1A0E es fácil de tratar, pues basta cambiar su CF por otro que apunte a nuestra rutina y ya lo tenemos interceptado. Una vez en la rutina hacemos lo propio: Si la contabilidad está activa, le restamos uno a CONTADOR y proseguimos con lo que hacía el $1A0E original, que no es más que un RET.
Un RET hace un POP de un WP "fuera" del Secuenciador, de ahí que CONTADOR se descuente por exceso.

Son muchas las palabras que llaman a $1A0E cuando se ejecutan durante la compilación de una palabra (sin usar el CALL), entre ellas ASCII. Con esto se soluciona el segundo BUG.

En cambio, el CALL $04B9 NO lo podemos interceptar, pues ya lo está, salta a la entrada 2 del Secuenciador.

La diferencia es que lo hace con CALL y no con un JUMP (JP) como hace normalmente nuestro viejo amigo el JP (IY) donde IY=$04B9 o similar.

Hacerlo con CALL es el truco que usa Ace Forth para entrar en el secuenciador desde c.m. y así poder ejecutar palabras Forth, pues CALL $04B9 es "equivalente" a hacer PUSH xx seguido de un JP $04B9, donde xx es la dirección del primer CA de la lista de CAs que componen las palabras Forth que queremos ejecutar y que vienen justo después del CALL.

Es un "falso" CALL, pues nunca va a retornar después de él. Es solo una manera de colocar en Rstack el WP del primer CA de la palabra Forth a ejecutar.

Y es este PUSH xx encubierto que se hace "fuera" del secuenciador el que provoca que CONTADOR se descuente por defecto.

Hemos de corregirlo sumándole uno. Pero primero hemos de detectar que se ha producido esta llamada a Forth desde c.m. Para ello, aprovecho que la rutina "toma nota" cada vez que se llama al secuenciador, por qué entrada se ha hecho. Entonces, si la entrada se ha hecho por el punto 2, solo tengo que comprobar si se ha hecho con un CALL $04B9. Como éste puso la dirección justo después de él en Rstack (pues es un CALL), no más tengo que copiarla y mirar si 3 bytes antes hay los bytes $CD $B9 $04 correspondientes a dicha instrucción. Si es así -> le sumo uno a CONTADOR.

(*) Era un problema cuando se usaba [COMPILE] ASCII en una definición.

[Elurdio]

Toco madera, pero tras unas cuantas pruebas parece que la cosa funciona bien.

Voy a ir documentando bien el Fuente de la Rutina maestra en c.m. y seguir haciendo pruebas. La idea es hacer un batería estándar de pruebas para realizarla tras cada modificación del Fuente.

De momento subo la nueva versión con el DEBUG y el DEBUGMC actualizados al primer Post. Las pongo aparte, no sea que haya problemas nuevos que no he detectado.

NO actualizo los fuentes. Tocaría actualizar el fuente de DEBUG y el del c.m. del depurador (así llamo también a la rutina maestra en c.m.) Lo haré más adelante.

[Elurdio]

Ace Forth NO permite que las palabras ." y ( están vacías. Tienen que contener al menos un carácter.

DEBUG da por supuesto que se cumple lo anterior.

Si se manipula la situación para que estén vacías, al depurarlas se mostrará basura como los 7 primeros caracteres del contenido.

Podría controlar si se da esta situación, pero al ser algo hecho por programa o a mano fuera de las reglas del Ace Forth, no lo toco, pues es un caso más de las "infinitas" posibilidades de "cosas raras" hechas por el usuario y que escapan al control de DEBUG.

[Elurdio]

DEBUG es una palabra Inmediata.

Se hizo así para poder depurar palabras inmediatas mientras se compilan en una definición. Si no lo fuera, se compilaría como una palabra más de la definición.

Ahora bien, esto puede llevar a errores si se hace un mal uso. Lo que aparentemente sería un posible BUG de DEBUG no es más que un mal uso del mismo.

Voy a poner un ejemplo muy tonto, pero clarificador.

Si hacemos : TEST DEBUG SWAP ; Obtenemos ERROR 5 (Word is not properly structured)

Si lo hacemos con la pila vacía, entramos en el depurador que nos muestra la palabra SWAP y un 10 en la pila. Ahora pulsamos "Step" y terminamos el depurado de SWAP que al ejecutarse nos cambia ese 10 con un número cualquiera (a saber cual) y cuando se ejecute el ";" espera encontrar el código de control 10 que puso ":" y como no está (SWAP lo ha cambiado por otro) -> ERROR 5

En resumidas cuentas, al usar DEBGU SWAP, como DEBUG es inmediato, y además, al depurar, la palabra que se depura se ejecuta, pues es como si hubiéramos utilizado un SWAP Inmediato, que en vez de compilarse y no hacer nada, NO se compila y se ejecuta.

Esto pasará con cualquier palabra que vaya precedida de DEBUG dentro de una definición.

El uso correcto de DEBUG dentro de palabras que se están definiendo es cuando la palabra que se depura es una COMPILANTE de Usuario (que además siempre son Inmediatas) o palabras Inmediatas en general. Como ya son inmediatas de por sí, se comportan como se espera -> Se ejecutan.

[Elurdio]

BUG (Solucionado) pero pendiente de actualizar el fichero .tzx del primer post, el fuente del c.m. y de añadir el fuente de la nueva palabra DSHOWR.

Acabo de descubrir un BUG que no es muy relevante.

Cuando se ejecuta DEBUG lista el contenido de Rstack (hasta 7 entradas máx.). Si el valor de la variable del sistema RAM (valor de memoria máxima disponible para Ace Forth) se altera, pues muestra valores de Rstack que NO nos interesan.

Ej. Si usamos DEBUG con el valor de RAM por defecto (cero) pues va bien, solo nos muestra un valor, el del WP de la siguiente palabra que se va a ejecutar. Los anteriores no nos interesan. Tienen que ver con la ejecución del Ace Forth, como 1300 de LINE, etc.

Pero si RAM tiene otro valor, como por ejemplo si estamos usando la rutina Cargador de Búferes, entonces muestra el susodicho WP y otros valores por debajo que NO son de nuestro interés, o incluso que NO forman parte de Rstack.

El BUG en sí no es grave, pero enreda. No creo que sea difícil de solucionar.

EDIT(23:21): El BUG es puñetero. En realidad el caso cuando RAM es cero es el que va mal, no el que va bien. El otro va mejor, pero no del todo, pues muestra algunos valores que NO son de Rstack.

Cuando imprimo el Rstack uso la misma palabra Forth emebebida en el c.m. DSHOW6 que uso para imprimir la pila actual y anterior, solo que ahora en sentido ascendente. El problema es que cuando se dispone de toda la memoria con el pack de 48k, la variable del sistema RAM vale 0 (el byte siguiente al último disponible es $FFFF+1=0) y esta tontería hace que DSHOW6 no me sirva.

No sirve porque uso como índice/límite las posiciones de memoria y entonces la límite es 0. De ahí que solo muestre un valor, pues se para por el límite de cero. He creado otra palabra por el estilo, que llamo DSHOWR que hace lo mismo pero usa un bucle contador del número de bytes y a cada vuelta lo suma a la dirección inicial.

EDIT(23:54): Solucionado el bug:

Ahora se muestra toda la pila Rstack (hasta un máx de 7 entradas) tal como estará cuando se ejecute la palabra que se muestra.

[Elurdio]

Cuando arrancas DEBUG name desde el búfer de entrada te muestra tres números en el Rstack.

Son tres WPs (Word Pointers)

El primero depende de la dirección de memoria que ocupa DEBUG en tu diccionario, pero los otros dos son fijos, son siempre los mismos pues apuntan a la ROM.

24417
 1300
 1273

El primero es 24417, que como he dicho será otro valor en tu caso, pues depende de la posición que ocupa en memoria la palabra DEBUG.
Es el WP que va indicando la palabra siguiente a la palabra en curso dentro del PF de la palabra cuyo PF se está ejecutando, que no es otra que el propio DEBUG.

1273 y 1300 son también WPs. Están relacionados con las palabras que se ejecutan durante el funcionamiento del Ace Forth.
El Ace Forth lo que hace al arrancar es entrar en un bucle infinito (se ejecuta continuamente) que es un palabra Forth que llamaremos MEL (de Main Execution Loop) en el que primero se ejecuta QUERY que nos permite escribir en el búfer de entrada, luego, cuando pulsamos ENTER nos ejecuta la palabra LINE que interpreta lo que hemos escrito y lo ejecuta. Luego ejecuta una palabra que imprime OK y luego una palabra que salta de nuevo al QUERY, y así contínuamente.

MEL al empezar a ejecutarse coloca un WP en Rstack (que será siempre el más profundo) y que cuando se empieza a ejecutar el LINE vale precisamente 1273 que es el valor del WP que apunta al siguiente CA, el de la palabra que pondrá el Ok cuando termine LINE.
El 1300 lo pone LINE al ejecutar una palabra que saca del búfer, y es un WP que apunta al siguiente CA dentro de LINE.

O sea, cuando ejecutamos DEBUG desde el Búfer de entrada, al mostrarse la palabra que se depura estamos a "profundidad" 3:

MEL->LINE->DEBUG

Si "name" corresponde a una palabra depurable, en cuento entremos en ella con "Step" pasaremos a "profundidad" 4:

MEL->LINE->DEBUG->name

Con lo que en Rstack tendremos un nuevo WP en la primera posición (4 números en Rstack) que depende de la dirección que ocupa "name" en la memoria.

Etc.

[Elurdio]

BUG (No solucionado aún)

Haciendo pruebas me he dado cuenta que cosas que antes iban bien ahora cascan. El fallo viene después de "arreglar" el tema de los número del Rstack que se muestran al depurar.

Concretamente he repetido la prueba de "depurar" una palabra tipo DEFINER mientras defino una palabra con ella.

Depuro 2CONSTANT mientras creo la constante doble KKK con ella así:

2 3 DEBUG 2CONSTANT KKK

Pues se vuelve loco del todo!

Usando una versión previa a tocar el "mostrado" del Rstack, todo va como la seda.

Nada, el problema es con mi diccionario maestro, algo se ha corrompido con tantos REDEFINEs y FORGETs (debe haberse sometido ya a varios cientos de REDEFINES/FORGETS).

Si uso el programa DEBUG cargado encima del maestro, funciona bien.

He probado de actualizar el DEBUG que hay en el diccionario maestro cargando el DEBUG original encima y sometiendo el conjunto a DELREPES que borrará las repetidas antiguas dejando las nuevas y al probar el DEBUG en el diccionario resultante casca igual.

Suerte que siempre guardo las 10 últimas versiones del diccionario maestro MAIN

[Elurdio]

Bug (pendiente de Solucionar) EDIT (7-4-2023): SOLUCIONADO

Afecta a las palabras de Usuario en c.m. tipo primitivas -> CF=PFA que llaman a palabras Forth desde c.m.:

Problema: Muestran las palabras Forth a las que llaman tanto si se hace "Step" como "Over". NO deberían mostrarse en ningún caso:

• Si se hace "Over" NO se debería mostrar lo que hace la palabra.
• Si se hace "Step" con una palabra de este tipo -> DEBUG le hace un "Over" automáticamente -> NO se debería mostrar lo que hace la palabra.

Lo detecté hace unos días probando +FLOOP que es todo c.m. y además hace una llamada desde código máquina a F+ que lo muestra cuando la depuras y no debería.

Hoy he hecho más pruebas y veo que es un fallo general. Por como acontece tiene visos de ser un problema del "Over".

Refloto este BUG pues NO está completamente solucionado (Pendiente de solucionar)

Lo que se comenta está solucionado pero ahora queda un problema:

Si después de la palabra en cuestión (la que daba este problema) hay más palabras, éstas NO se depuran.

No me di cuenta porque casualmente todos los casos que probé la palabra con el BUG era siempre la última.

Estoy fatal!! Creo que me voy a tomar un descanso...

NO existe tal BUG, lo que pasa es que después de arreglar el último BUG (el del listado del Rstack) no sé que me empatollé que he mezclado la palabra Forth DEBUG antigua con el c.m. del depurador último en un mismo DEBUG.TZX

Antes de empezar con el "penoso" rastreo del BUG con el Z80 Debugger, puse un Breakpoint para comprobar una de las interceptaciones que sospechaba estaba detrás del BUG y cual fui mi sorpresa al ver que el programa NO se paraba... La palabra Forth DEBUG que es la que sobreescribe las interceptaciones era antigua y ésta interceptación NO se hacía.

En cuanto solucione todo este guirigay pongo en el primer post el .TZC correcto y cambio el fuente de DEBUG en el 2º post que tiene una versión intermedia, ni la antigua ni la última.

EDIT: Solucionado.

[Elurdio]

Acabo de hacer una prueba "aproximada" para ver hasta que punto la interceptación con todo los procesos que se realizan durante la misma afectan a la velocidad de ejecución de las palabras.

He definido una palabra que realiza un bucle 100 veces con índice de 0 a 99. A cada ciclo imprime Indice*Indice (el cuadrado del índice). Incluye palabras que cronometran la duración total y que usan dos pares de IF/THEN en cada ciclo. Están puestas de tal modo que puedo probar el comando "Loop" del DEBUG sin alterar el cronometraje, pues el mismo empieza a partir del segundo ciclo (el primer ciclo NO se cronometra)

Haciendo un "Exit" (con BreakPs activados y desactivados pero sin haber ningún BreakP puesto), un "Over" y un "Loop" dan casi los mismos tiempos.
El "Exit" y el "Over" se hacen a la primera parada de DEBUG y el "Loop" a la primera aparición de la palabra LOOP.

Cuando usamos DEBUG tal como hemos detallado, una vez escogida cualquiera de las tres opciones indicadas, la palabra se ejecuta normalmente, sin interrupciones ni mostrándose en ningún momento la pantalla del DEBUG. La diferencia radica en que con DEBUG se usa el Secuenciador modificado, pues el original está interceptado y se redirige a aquél.

Ejecutada Normalmente: 1.0 segundos
Ejecutada con DEBUG:  21.4 segundos

Como podemos ver, la interceptación tiene un fortísimo impacto en la velocidad de ejecución.

[Elurdio]

BUG (Pendiente de Solucionar)

Usando una variante de DEBUG para detectar qué primitivas del Ace Forth (ROM) llaman a Forth desde c.m. (ver este post del hilo Utilidades II), me he encontrado con una situación que no preví.

Cuando se "depura" la palabra INT, al ser una primitiva en c.m. de la ROM, NO se depura (se usa "Over" automáticamente). Pero resulta que DEBUG muestra una palabra que INT utiliza. Es una Headerless por lo que se imprime un nombre "raro".
Muestro a continuación el resultado de hacer 7.5 DEBUG INT que deja un 7 en la pila.

raroname.png (602 Bytes) Visto 480 veces

El nombre que se ve justo debajo de INT, la letra D precedida de un símbolo gráfico (basura) es el nombre que casualmente se le asigna a dicha palabra Headerless (*). NO debería verse, pues INT se supone que no se depura.

Resulta que INT, que está en c.m., internamente realiza un EXECUTE con el CFA de la palabra Headerless. Y precisamente esto es lo que NO tengo previsto:

BUG: No he contemplado en DEBUG que se realice un Over a un EXECUTE, de ahí que el "Over" automático NO tiene ningún efecto sobre EXECUTE.

De hecho el comando "Over" NO tiene efecto sobre EXECUTE ni activado a mano ni automáticamente por el propio DEBUG.

NOTA: EXECUTE cuando se depura siempre muestra la palabra correspondiente al CFA que ejecuta, incluso si es una Headerless. No tengo bien resuelto el tema de EXECUTE, que es la única palabra (creo recordar) que entra por el punto de entrada número cuatro del Secuenciador.

En definitiva, INT NO es una palabra 100% en c.m., pues llama a Forth desde c.m. pero de una manera que no tuve en cuenta, en vez del modo habitual, pues lo que hace es usar internamente EXECUTE para ejecutar una palabra tipo COLON Headerless.

(*) Cuando se intenta imprimir el nombre de una palabra que NO lo tiene, tanto si lo intento yo como si lo intenta el propio Ace Forth, se aplica un procedimiento que en el caso de la Headerless le asignará un nombre "por casualidad" (aunque siempre será el mismo). Este procedimiento detecta la dirección donde se supone empieza el nombre y luego imprime todos los caracteres a partir de esa dirección hasta que encuentra uno con el bit#7 activado, que lo considera el último y lo imprime con ese bit apagado.

[Elurdio]

Estudiando las palabras de la ROM que realizan "execute" interno (entran por el cuarto punto de entrada del secuenciador) me he encontrado con una Rutina en c.m. que lo utiliza.

Es una rutina que imprime el valor en HL en pantalla como número entero con signo y que preservar el registro BC.

Me he hecho la palabra MI. en c.m. que simplemente carga HL con un número y llama a esta subrutina con un CALL y luego termina (vuelve a Forth).

Al hacer DEBUG MI. obtenemos:

raroname2.png (672 Bytes) Visto 466 veces

DEBUG solo debería mostrar el MI. y luego el DBG->END, pero muestra también la palabra "." (punto) que es la que llama la Rutina con un "execute" interno pero que continúa ejecutando otra palabra en vez de volver a Forth. Esta palabra es una Headerless que se utiliza como un "truco" para seguir ejecutando c.m. que acaba con un RET después del "execute" interno y es la responsable de la basura que hay en la tercera línea.

Consultar este post para los detellas.

[Elurdio]

Dándole vueltas al por qué dejé EXECUTE así (fue casi "ayer" y ya no me acuerdo) creo entrever el motivo.

Si durante la depuración de una palabra nos encontramos con EXECUTE, éste toma el CFA de la pila y ejecuta la palabra correspondiente.

Si hacemos "Over", éste se aplica a la palabra EXECUTE, pero NO a la palabra que es ejecutada por EXECUTE, pues ambas están a la misma "profundidad" (al mismo "nivel")

Es como si en una definición de una palabra que estoy depurando hay la palabra A seguida de la palabra B. Si cuando se ejecuta A selecciono "Over" pues la palabra A no se depurará y luego vendrá B que le puedo o no aplicar Over. El Over apliacado a A se termina en cuanto A termina. Pues con EXECUTE pasa algo similar, A es EXECUTE y B es la palabra que EXECUTE ejecuta. Son independientes.

Podría hacer que lo que se ejecuta con EXECUTE no se depure, pero esto puede no ser lo que queremos si EXECUTE ejecuta una definición COLON de Usuario, pues queremos poder decidir nosotros si se depura o no.

Pero hay algo más. El mismo DEBUG cuando empieza depurando una palabra, primero arranca la interceptación y luego ejecuta dicha palabra (la que le sigue) mediante EXECUTE. Si ésta no mostrara lo que ejecuta, pues NO se depuraría nada. De ahí, que lo dejé así.

Ahora veo que esta decisión puede traer problemas. Así que no me queda otra que "solucionarlo" de alguna manera.

[Elurdio]

En principio acabo de solucionar el Bug del EXECUTE, tanto si es la palabra normal como si se ha usado desde c.m. internamente.

De momento NO actualizo a la nueva versión de DEBUG, porque la cosa ha sido más complicada de lo que me esperaba y he tenido que toquetear bastante (*). Esperaré a probarla más y ver que al solventar este BUG no he creado otros problemas.

Ahora cualquier EXECUTE interno desde c.m. NO muestra la palabra que llama ni la depura se pulse lo que se pulse.

Si el EXECUTE es el normal (el Forth), si se pulsa otra opción que NO sea "Step" pues tampoco mostrará la palabra que se ejecuta ni la depurará. Pero si pulsamos "Step" estando en el EXECUTE entonces, si la palabra que se ejecuta NO es una primitiva(ni de usuario ni de ROM), mostrará la palabra en cuestión y la depurará.


(*) El nivel de "parches" acumulados está empezando a acercarse al punto de "borrón y cuenta nueva" y tener que volver a reescribir la rutina sin tanto parche. Cada vez es más ininteligible...

[Elurdio]

Tras unas cuantas pruebas "parece" que la solución del último BUG no ha creado nuevos problemas.

Aprovecho para poner la versión nueva de la palabra MC? que detecta si una palabra es una primitiva teniendo en cuenta el "tercer" tipo que actualmente no se considera, a saber, las que llaman a la ROM.

Se han actualizado:

El fichero DEBUG.TZX, los fuentes de ISMACHINE? y sus palabras auxiliares (nuevas: R> y MCROM?) y el fuente de la rutina maestra en c.m. DEBUG.ZIP en sus respectivas páginas.

[Elurdio]

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.