Programar en Forth

[Ecalius]

Hola compañeros!!!

¿Habeis programado alguna vez en Forth? ... Ya sabeis, ese lenguaje inventado por Charles Moore, que
es simple, compacto, y veloz de ejecución, y que pretendía ser un sustituto del basic, y el ensamblador, ayudado por
un diccionario de palabras ampliable, y el manejo de 2 pilas, la de datos y la de direcciones.
¿Es posible hacer buenos juegos en Forth?
¿Alguno de vosotros en su día hizo un juego? ... explicarme vuestra experiencia, estoy estudiando la posibilidad de hacer
juegos para Spectrum en este lenguaje.

Saludos!!!

[Gandulf]

Pues ni idea. Ese lenguaje nunca lo he utilizado pero me suena que se emplea para temas de matemáticas y cálculos físicos.

Puede ser una experiencia programar un juego en este lenguaje, pero sin conocerlo, dudo mucho que sea lo más recomendable para este fin

[winston]

Pues ni idea. Ese lenguaje nunca lo he utilizado pero me suena que se emplea para temas de matemáticas y cálculos físicos.

Según Wikipedia, FORTH se usaba también para fines científicos, pero en aquella época, casi cualquier lenguaje de programación era diseñado para estas cosas. Pues... por supuesto, excepto COBOL

[Gandulf]

Ahora me queda la duda de si era Forth o fortran, es que me comentara creo que un Teleco que antiguamente estudiaban programación en este lenguaje (ahora trabajan con C y cosas más al uso)

[mcleod_ideafix]

Gandulf, el lenguaje que tú dices es Fortran. El Forth se usó, que yo recuerde, en el Jupiter Ace. Hay un ¿intérprete? para Spectrum.

El Fortran se sigue usando... ¡vaya que si se usa! Se usa sobre todo en entornos de supercomputación, ya que hay científicos que sin necesitar una base sólida de programación, como hace falta para usar C para resolver problemas puramente matemáticos, necesitan un lenguaje fácil de entender, sin las "sorpresas" de C (léase: la forma en que usa vectores y matrices al pasarlas como parámetros a una función), y que sea rápido, esto es, compilado. El middleware que se usa en supercomputación (MPI, PVM, etc.) soporta C y Fortran.

En otro orden de cosas, Forth es el lenguaje que se ha usado para la autoconfiguración de tarjetas de periféricos en máquinas Sparc (cuando usan el bus propietario de Sun... ¿NU-BUS?: cada tarjeta lleva un pequeño intérprete de Forth embebido, y el controlador de bus envía comandos Forth a cada tarjeta para configurarlas. No sé los detalles de cómo se hace esto.

Hace cosa de dos años encontré este libro: "Thinking Forth", en donde el autor promueve el uso de Forth como una nueva forma de pensar en cómo resolver los problemas, etc.

[winston]

Si no mal me recuerdo, se usa "reverse polish notation" para expresiones matemáticas en el Jupiter Ace, aunque no estoy seguro...

En el RPN, una expresión tal como 1+2+3 se escribe:

1 2 + 3 +

Creo que hay calculadores programables de HP que usan RPN también.
Algun día, me gustaría hacer una calculadora de RPN con tubos de nixie

[Ecalius]

Navegando por la red he encontrado un compilador de Forth para nuestro querido Spectrum, el Forth de Abersoft, creo
que es el mejor que existía en la época, y ocupa sólo 10Kb en memoria.
Ahora mismo estoy leyendo un libro en formato PDF, llamado "Advanced Spectrum Forth", en inglés, de Don Thomasson,
de la editorial Melbourne House Publishers, y que lo podeis encontrar en la web de "World of Spectrum".
El compilador de Abersoft también lo podeis descargar de allí.
El libro está muy bien, y se dirige al mismísimo Forth de Abersoft.
......
Ayer estuve mirando los juegos de Jupiter Ace, que solían ser de 3kb, y algunos de 19ks, y me parecieron muy interesan-
tes para estar echos en Forth. Habian documentos que explicaban cómo los programadores de Forth se hacían sus propios
diseños de los juegos, y sus carátulas de las cintas... etc .
La verdad es que era muy gratificante, ví juegos que nunca se llegaron a vender, pero que yo mismo lo considero pequeñas
obras maestras de la programación.

[Ecalius]

Hola amigos!!!

Hacía tiempo que no me conectaba, y es que he tenido mucha faena en mi humilde trabajo, y entre las navidades
y las comidas familiares no he podido centrarme en este mundillo.
Bueno, sigo pensando que el Forth salió en mal momento, y no se pudo aprovechar toda su potencial para hacer
juegos, en vez de Basic o Assembler. A parte, si la gente ya había aprendido Basic, ¿porque liarse con un lenguaje
extraño cuando lo miras?... Este año me he propuesto aprender bien Forth, y realizar un pequeño juego para
demostrar a todo el mundo, pero sobretodo a mi mismo, que Forth podría haber "calado fondo" en la gente, el juego
que intentaré desarrollar será el clásico "ASTEROIDS", y cuando terminé dejaré el código fuente al servicio para quien
quiera estudiarlo.

Estudiando los compiladores disponibles para nuestro querido ZX SPECTRUM, he encontrado 2, uno es el FIG-FORTH de
Abersoft, y otro el FORTH INVESTRóNICA de Artic, y los he comparado en velocidad para el siguente programa de prueba
en BASIC, que a parte lo he compilado con Hisoft Basic, y también lo he comparado, aquí teneis:


10 FOR X=0 TO 255
20 FOR Y=0 TO 175
30 PLOT X,Y
40 NEXT Y
50 NEXT X

El programa rellena la pantalla del Spectrum con pixels, el código FORTH que he empleado para esto es el siguente:

0 VARIABLE X
: TEST 176 0 DO X @ I PLOT LOOP ;
: TESTXY 256 0 DO I X ! TEST LOOP 0 X ! ;

TEST

La tabla de comparaciones es:

ZX BASIC : 6 min 13 seg
HISOFT BASIC: 1 min 32 seg
ARTIC FORTH (INVESTRÓNICA): 1 min 24 seg
ABERSOFT FORTH (FIG-FORTH): 0 MIN 20 SEG

Por lo tanto, el mejor para programar es el de Abersoft, aunque el de Investrónica tiene el manual en castellano, y el
otro está en inglés.

Bueno, espero que este proyecto vaya adelante, y "ASTEROIDS" en Forth sea una realidad, un saludo a todos !!!!

[na_th_an]

Mucho ánimo, me parece muy interesante lo que estás haciendo.

Bueno, sigo pensando que el Forth salió en mal momento, y no se pudo aprovechar toda su potencial para hacer
juegos, en vez de Basic o Assembler.

Bueno, Forth fue desarrollado entre 1965 y 1970 para facilitar la tarea de hacer cálculos astronómicos en el observatorio de Kitt Peak, en Arizona, no sé a qué mal momento te refieres

[...]El programa rellena la pantalla del Spectrum con pixels, el código FORTH que he empleado para esto es el siguente:

0 VARIABLE X
: TEST 176 0 DO X @ I PLOT LOOP ;
: TESTXY 256 0 DO I X ! TEST LOOP 0 X ! ;

TEST

La tabla de comparaciones es:

ZX BASIC : 6 min 13 seg
HISOFT BASIC: 1 min 32 seg
ARTIC FORTH (INVESTRÓNICA): 1 min 24 seg
ABERSOFT FORTH (FIG-FORTH): 0 MIN 20 SEG

Impresionante. Estaré atento a tus progresos.

[Ecalius]

Hola amigos, os voy a explicar mi pequeña experiencia con el lenguaje Forth de Abersoft.

Cómo comenté anteriormente, quiero hacer el juego ASTEROIDS, los gráficos los he podido realizar a mano en una libreta
cuadriculada, utilizando el sistema artesanal de rellenar los cuadritos que representan los pixels, hasta aquí ningún problema.

Después pensé cómo los representaría en pantalla, en forma de UDGs, con lo cual necesitaría varios bancos de gráficos para
representarlos, y el movimiento se limitaría a baja resolución 32 columnas x 24 filas, 768 posiciones y de 8 en 8 pixels, lo cual
no me satisfacía. Hize una prueba en Forth de utilizar la palabra PLOT para imprimir sprites punto a punto y así utilizar 256 x 192,
49152 posiciones y de 1 a 1 pixel, pero la velocidad de representación era pésima.

Ahora estoy desarrollando las rutinas que imprimen un sprite en alta resolución, pero accediendo directamente a la memoria de
pantalla, pero todavía no lo he acabado, y aún no puedo deciros si merece la pena. La verdad es que programar en FORTH me
cuesta bastante, a veces me es más fácil utilizar el ensamblador. También pienso, porque FORTH tiene muchísimas palabras, y
las instrucciones están en inglés ( Advanced Spectrum Forth, es un libro en el que me baso para programar ).

Quizás me plantee crear un pseudoForth muy básico, a nivel de assembler, más bien compilado, utilizando la estructura de palabras
de la que se rige, y con él desarrollar ASTEROIDS , o más bien pensármelo y utilizar el assembler que me es más familiar .

Aquí teneis un ejemplo de mi primera incursión formal en FORTH de Abersoft, la palabra que calcula la dirección en pantalla según
coordenadas X,Y:

( CALCDIRPANT: Calcular direccion pantalla )

0 VARIABLE COORDX ( 0 a 255 )
0 VARIABLE COORDY ( 0 a 191 )
0 VARIABLE COL ( 0 a 31 )
0 VARIABLE FIL ( 0 a 23 )
0 VARIABLE BASEPANT ( 16384 18432 20480 )
0 VARIABLE LINEA ( 0 a 191 )
0 VARIABLE NUMLINEA ( 0 A 7 )
0 VARIABLE DESPNUMLINEA ( 0 256 512 768 1024 1280 1536 1792 )
0 VARIABLE DESPFIL ( 0 32 64 96 128 160 192 224 )
0 CONSTANT FALSE
1 CONSTANT TRUE

: COLUMNA COORDX @ 8 / COL ! ;
: FILA COORDY @ 8 / FIL ! ;
: TERCIO1? FIL @ 8 < IF TRUE ELSE FALSE ENDIF ;
: TERCIO2? FIL @ 16 < IF TRUE ELSE FALSE ENDIF ;
: DIRBASEPANT TERCIO1? TRUE = IF 16384 BASEPANT ! ELSE
TERCIO2? TRUE = IF 18432 BASEPANT ! ELSE
20480 BASEPANT ! ENDIF ( Esta en tercio 3 )
ENDIF ;
: LINEA0ALTA FIL @ 8 * LINEA ! ;
: NUMLINEAFILA COORDY @ LINEA @ - NUMLINEA ! ;
: DESPLAZA1 NUMLINEA @ 256 * DESPNUMLINEA ! ;
: DESPLAZA2 TERCIO1? TRUE = IF FIL @ 32 * DESPFIL ! ELSE
TERCIO2? TRUE = IF FIL @ 8 - 32 * DESPFIL ! ELSE
FIL @ 16 - 32 * DESPFIL ! ENDIF ( Esta en tercio 3 )
ENDIF ;
: DIRPANT BASEPANT @ DESPNUMLINEA @ DESPFIL @ COL @ + + + ;

: CALCDIRPANT COLUMNA FILA DIRBASEPANT LINEA0ALTA NUMLINEAFILA DESPLAZA1 DESPLAZA2 DIRPANT ;

( Fin de CALCDIRPANT )

La palabra CALCDIRPANT previamente habiendo introducido en las variables COORDX y COORDY las coordenadas de pantalla,
dejará en la pila la dirección de pantalla. Cómo habreis visto, FORTH es bastante modular, debes crear las palabras base iniciales,
para que la palabra principal funcione, esto te obliga a programar de abajo hacia arriba. No se si esto es bueno o es malo ¿?.

Bueno compis, hasta pronto !!!

[Boriel]

Bueno, en ZX BASIC (el compilador, no el intérprete de la ROM), tarda unos 11 segundos aprox (me gustaría que alguien más lo midiera).

Código: Seleccionar todo

10 DIM X as Uinteger
20 FOR X = 0 TO 255 
30 FOR Y = 0 TO 175 
40 PLOT X, Y
50 NEXT Y
60 NEXT X

Compilar con zxb -O3 -TaB plot.bas
(No puedo subir adjuntos al foro, pero pueden descargar el tzx de aquí: http://www.boriel.com/files/zxb/plot.tzx )
Nota: El compilador usa las 192 líneas, así que habría que poner de 0 a 191 para que las rellene toda la pantalla.

[mcleod_ideafix]

A mi me salen 9 segundos usando este código (que se cronometra él mismo):

Código: Seleccionar todo

DIM x,y as uinteger
DIM ti,tf as ulong
ti=peek(23672)+256*peek(23673)+65536*peek(23674)
FOR y = 16 TO 191
  FOR x = 0 TO 255
    PLOT x,y
  NEXT x
NEXT y
tf=peek(23672)+256*peek(23673)+65536*peek(23674)
print at 23,0;(tf-ti)/50
pause 0

Como referencia, una versión en ensamblador puro que use la rutina de la ROM para dibujar el punto, como ésta:

Código: Seleccionar todo

plotbc                  equ 22e5h  ;B=y, C=x

                        org 32768
                        ld b,175
buclinea                ld c,255
bucpunto                push bc
                        call plotbc
                        pop bc
                        dec c
                        jp nz,bucpunto
                        djnz buclinea
                        ret

                        end 32768

Me tarda 7,32 segundos, medido de esta forma:

Código: Seleccionar todo

10 LET ti=PEEK 23672+256*PEEK 23673+65536*PEEK 23674: RANDOMIZE USR 32768: LET
 tf=PEEK 23672+256*PEEK 23673+256*PEEK 23674: PRINT #0;AT 1,0;(tf-ti)/50: PAUSE 0

[na_th_an]

Por lo que queda demostrado que el compilador de Boriel es la repanhostia en babuchas Felicidades, debes estar orgulloso.

[mcleod_ideafix]

Por lo que queda demostrado que el compilador de Boriel es la repanhostia en babuchas Felicidades, debes estar orgulloso.

Pues fíjate que precisamente hay una diferencia aún bastante evidente entre la versión en ZX Basic y la de ensamblador, aunque las estructuras de control que se usan en ZX Basic admiten todo tipo de optimizaciones. La razón por la que tarda hasta 2 segundos más es porque no me ha dejado usar variables de tipo UBYTE para x,y sino que he tenido que usar UINTEGER, es decir, de 16 bits. Con x,y de tipo UBYTE el programa no funcionaba correctamente. El motivo es éste:

Código: Seleccionar todo

   ld a, (_x)
   ld h, a
   ld a, 255
   cp h
   jp c, __LABEL9

El salto condicional a __LABEL9 jamás se toma, porque la condición jamás es cierta. Pero aún así, es posible escribir bucles que den 256 vueltas usando índices de 8 bits. Podría merecer la pena que el compilador estudie el caso de bucles cuyo índice es una variable de tipo byte, para codificarlos metiendo el índice en el registro B y usando DJNZ (vamos, lo que sería una variable de tipo "register" en C).

Teniendo en cuenta esto, he modificado el programa para que X sea entera, e Y de tipo byte (con Y no pasa esto, claro) y ahora obtengo... lo mismo! 9 segundos.

¿Por qué el código que compara un valor de byte con un número inmediato se codifica así:

Código: Seleccionar todo

   ld a, (_y)
   ld h, a
   ld a, 191
   cp h
   jp c, __LABEL3

en lugar de hacerse así?

Código: Seleccionar todo

   ld a, (_y)
   cp 191
   jp c, __LABEL3

Es decir, fíjate que es como si se usara la misma plantilla de generación de código en 8 y 16 bits. Así se hace en 16 bits:

Código: Seleccionar todo

   ld de, (_x)
   ld hl, 255
   or a
   sbc hl, de
   jp c, __LABEL9

Aquí hay el mismo patrón que en 8 bits: se usan registros de 16 bits, claro, y la inexistente instrucción CP DE,HL se codifica con OR A ; SBC HL,DE . Dado que el Z80 es un micro de 8 bits, se deberían favorecer las operaciones de 8 bits de alguna forma, ¿no? Tal y como se codifican ahora, hay poca diferencia (en tiempo de ejecución) entre usar variables de 16 bits y usar variables de 8 bits.

Voy a ver si puedo hacer pruebas con el SDCC, a ver cómo se comporta con este tipo de bucles...

[Boriel]

Creo que algo no está funcionando bien en el optimizador (-O3) de mirilla.
Por ejemplo, la secuencia de código:

Código: Seleccionar todo

ld a, (_y)
inc a
ld (_y), a

Debería traducirse a

Código: Seleccionar todo

ld hl, _y
inc (hl)

pero no lo está haciendo, pese a que se puede. Qué mosca...

Igualmente, el patrón de código que se comenta de la comparación de 8 bits no está optimizado. Ese puede que me haya olvidado de codificarlo. Lo haré para la siguiente versión.

Por último, el FOR de BASIC es un poco especial, ya que en realidad, si fuera en C se codificaría como

Código: Seleccionar todo

for (x = 0; x <= 255; x += STEP) {
...
}

Es decir, tenemos un <= y además, el tamaño de paso (STEP) es variable. Sería detectar un caso o 2 casos muy concretos y el coste puede no valer la pena. Por ejemplo, haciendo LD B, 0 es posible usar DJNZ para hacer bucles de 256 iteraciones con un byte, pero si el cuerpo del bucle es muy largo pueden pasar dos cosas: Que el djnz no llegue al comienzo del bucle (es un salto relativo de -128 bytes como mucho) o que el registro B sea alterado en algún paso intermedio.

Para rutinas críticas (emisión de sonido, etc.) incluso los juegos comerciales usan ensamblador hoy día (o ANSI C). Pero bueno, iré mirando qué puede hacerse... Gracias!