:R4

La sintaxis hace al lenguaje mas simple o mas complejo.

Años mas tarde, el Dr. Vaporeso intenta llegar a misma conclusión pero lo dice mal.

Igualmente Moore no conoce al Dr. Vaporeso, y este, no conoce la sintaxis.

La forma mas simple de un compilador para un lenguaje tipo FORTH es asignar un fragmento de código en assembler y copiar el fragmento correspondiente a la palabra a compilar, asi de simple, ningun otro lenguaje permite compilar de esta manera, por supuesto el resultado es desastroso.

En el editor, presionando F10, se producen dos archivos en la carpeta f4asm, cod.asm y dat.asm, el código se genero de la manera anteriormente explicada.

La forma de optimizar esto es utilizando todos los registros disponibles para evitar el uso de la pila de datos, ya que esta debe ser simulada con unregistro y una porcion de memoria. En resumen, desaparecer la pila de datos y reemplazarla por registros que significan determinado lugar en la pila.

Seria ideal tener tantos registros como lugares en la pila se necesitan para ejecutar un programa, aunque parezca mentira no son tantos estos lugares, pero los registros del x86 son una miseria !!

El primer analisis que realizo sobre las definiciones es justamente la profundidad de la pila que usa, llamo USO a la cantidad de lugares que utiliza, delta Datos y delta R a la variacion de las pilas. por ejemplo DUP tiene uso 1 y dD +1, Puede verse en r4post la tabla completa del diccionario base, este primer analisis estatico que se hace.

En R4post.txt tambien esta el analisis de llamadas entre palabras, hace una busqueda en profundidad del arbol de ejecucion contando la cantidad de llamadas y si se utiliza la direccion o no para saber si una variables es en realidad una constante y para saber si una definicion puede modificarse su inicio si nadie utiliza su direccion (funciones inline).Estoy en desarrollo de un analisis mas profundo donde el funcionamente principal esta en vtstack.txt, aqui armo la pila de manera estatica asignando registros virtuales (como si tubiera muchos registros) y contabilizo el uso que se les da, por ejemplo:

3 +

3 es marcado como registro que es constante, luego + utiliza este registro y no esta mas, no tiene costo mas que la suma, entonces es una constante que no hace falta en la pila

3 ( 1? )( 1- ) drop

Aqui pasa algo distinto, el 3 que es marcado como registro y constante, el 1? lee este registro pero no opera sobre el, luego es utilizado por 1- para modificaro, entonces sumo 1 al uso de este registro, luego lo borro, no lo uso mas, entonces si quiero eliminar la celda de la pila que contiene este 3 lo puedo asignar a un registro, por ejemplo ebx y lo logica del manejo de pila desaparece para este registro virtual!!

Un poco mas de documentacion en el desarrollo del compilador.

Bytecodes
La MV de :r4 genera bytecodes para ser ejecutado y, para evitar una indireccion mas y ganar en velocidad, las direcciones son absolutas con respecto a la memoria donde se genera, por eso, con algunos cambios de versiones los archivos .r4x no funcionan, habia que generarlos otra vez.Por esta razon tambien, al ser las direcciones de datos y codigo absolutas, una vez generada la imagem, si estas direcciones se ubican en otro lugar, no hay forma de saber cuando un numero representa una direccion o un numero literar. Un pequeño ejemplo
si la variable “x” tiene la direcion 1000 y existen dos definiciones de variables, “x1″ y “x2″ asi

#x1 'x
#x2 1000


el codigo generado como bytecodes sera:
x1 contiene 1000 y x2 tambien contiene 1000, si esta direccion cambia a 500…no puedo saber que x1 debera tener 500 mientras que x2 debera tener 1000.

Tokencodes
Para resolver esto sin tener que reescribir el compilador decidi hacer otra representacion del codigo generado, lo llame tokencodes, agrege 11 nuevos codigos con informacion util para analizar, como donde estan las definiciones, separar las direcciones por su tipo etc.( ver r4token.txt).Estos tokencodes poseen la informacion necesaria para analizar,debugear e inclusive simular su ejecucion (r4code.txt).
Ejemplo de lo que se puede hacer con tokencodes es r4plain.txt, donde utilizando esta estructura genero el codigo de otro codigo reemplazando los nombres de palabras por una”normalizacion” de dichos nombres e ignorando las palabras que no son llamadas (codigo muerto) en solo 96 lineas !!

Compilador
Existio en un momento un compilador con optimizador muy rudimentario, que mantenia el control de la palabra anterior para compilar, el codigo generado no alcanzaba a ser decente asi que abandone ese enfoque inmediato esperando conocer un poco mas de la generacion de codigo.Cuando retome el trabajo, quise resolver todas las optimizaciones en un solo lugar, pero a poco de andar me di cuenta que podia resolver la optimizacion en dos aspectos:
1. cuestiones de reescritura de codigo, por ejemplo: 2 2 + puede reescribirse como 4, o palabras “inline” o variables que son constantes, etc.
2. cuestiones referentes a la arquitectura del asm que genero, por ejemplo asignacion de registro, obligatoriedad de usar determinado registro para determinada instruccion, etc.
Entonces las optimizaciones del tipo 1 las resuelve (actualmente funciona y creo que bien), r4plaino.txt. y las optimizacion del tipo 2 son el proximo post

Lo convierto a numero si realmente necesito que sea asi.

value 2 << ‘listactions + @ exec | :r4

Aqui mi lista.

* Punteros a memoria de datos:
Los punteros transforman el significado de un numero, de cantidad o lugar, a un nivel superior, otro significado.

* Puntero a memoria de código:
Para variar el significado dentro de la ejecución, o para hacer listas de acciones, para construir ON GOTO del viejo BASIC.

* No tener Garbage Collector (GC):
No es necesario ordenar la memoria cuando ya esta ordenada, el mejor GC es el que no esta !!, como siempre digo, si hay GC hay también un Garbage Generator.

* Tipo de datos estáticos:
Fundamental para entender que esta pasando en la memoria, un tipo de datos dinámicos es un excelente generador de basura.

* Coherencia en la generación de código:
Programar no debería convertirse en una lucha con el compilador, el infierno de los CAST de C y sus derivados para convencer al compilador que realmente queremos acceder allí.

Los argumentos para quitar o agregar estas y otras características parecen sacados de una propaganda de cerveza.
Estoy cansado de escuchar argumentos vacíos acerca de los beneficios de un lenguaje que se invento para interferir entre el programa y la maquina.
Quizás en unos años salga OTRA nueva computadora y para programarla se utilizara

http://en.wikipedia.org/wiki/Eiffel_(programming_language)

ya que si apple resucito el OBJ-C!!

Después de organizar un poco y pensar para que carajo sirve un blog, decidí usarlo como pila de ideas ahi va la primera.

Tratando de descifrar como deberia trabajar el compilador estuve compilando a mano palabras con cada vez mas complejidad, por ejemplo: gr_mix de asmbase esta generado unas 100 lineas de asm, compilado a mano me da 24 lineas.. algo asi

:gr_mix | a b al -- c
>r                push eax
dup             mov ebx,[esi]
$ff00ff and     and ebx,$ff00ff
pick2           mov eax,[esi+4]
$ff00ff and     and eax,$ff00ff
over -          sub eax,ebx
r *             cdq
imul dword [esp]
8 >>            sar eax,8
+               add ebx,eax
$ff00ff and     and ebx,$ff00ff
rot
rot
$ff00 and       mov ecx,[esi]
and ecx,$ff00
swap
$ff00 and       mov eax,[esi+4]
and eax,$ff00
over -          sub eax,ecx
r> *            pop ebx
cdq
imul ebx
8 >>            sar eax,8
+               add eax,ecx
$ff00 and       and eax,$ff00
or ;            or eax,ebx
lea esi,esi+8
ret

La administracion de los registros es clave, arme un esquema simple y vamos a ver como funciona, que lastima que x86 tenga tan pocos registros, seguramente en ARM o POWERPC deberia funcionar mejor.

Hace una semana que empezo a funcionar el nuevo compilador, para probarlo.. f2 para editar archivo..f2 para debug..f11 para generar asm… despues de generar cod.asm y dat.asm en /r4asm se compilar y se ejecuta.. los poligonos con degrade y textura todabia no tienen codigo.

El compilador todavia no optimiza nada, es decir, el codigo es realmente malo, por ejemplo el PONG genera un exe de 29kb..ya veremos cuanto se achica con el optimizador..

Estoy haciendo una lista de las posibles optimizaciones, si alguien se acuerda o se le ocurre otra, por favor avisen..

* Resolver constantes.. 4 5 + —> 7

* juntar operadores.. 4 + —> no apilar 4 sino compilar add xx,4

* reemplazar constantes de multiplicacion, en un principio solo potencias de 2 a desplazamientos

* tail call (no se como traducir esto), es cuando el ultimo call de una palabra se transforma en jmp

* invertir condicion cuando se salta a una palabra, 1? ( w ; ) —> jz W

* reemplzar pila R cuando se usa como auxiliar, con un verdadero registro auxiliar (edi)

* eliminar movimientos de pila, asignando los registros disponibles a la pila

* quitar definiciones anonimas por definiciones separadas

* resolver palabras inline cuando sean chicas y sea posible..

a ver cuantas de estas puedo resolver y cuanto se achica el codigo…