Diste en el clavo del tema que quise explicar cuando publique ese codigo.
El PBP trabaja en background con macros.
Si miras en el directorio donde compilaste el programa veras un archivo del mismo nombre con extension .mac, entre otros.
Cada comando aumenta en forma increible el tamaño del codigo, es mas cuando repites muchas veces la misma instruccion (la peor es LCDOUT) se agranda en forma desproporcionada el tamaño del .hex resultante.
Imaginate que aun en ensamblador tu archivo tiene pocas lineas, cuando agrandas el programa se porta peor.
Pero si un Team de programadores uso ese esquema en assembler, porque lo hicieron asi??, no saben ellos programar funciones con pasada de parametros??
A mi entender son bastante genios y duchos en assembler, me parece fantastico que podamos disfrutar de una herramienta de ese tipo, pero por que no lo hicieron de otra forma??
No saben o no pueden??
La comparacion de tamaño de codigo yo la hice en su momento en Assembler, Basic y C.
Optimize aun mas en assembler al usar el Carry para rotar bits en las tramas de cada byte recibido.
Creo que me dio unos 57 KB el assembler, unos 64 a 65 KB el C y unos 128 KB el B, que es el mismo que enviaste.
Como seguimos??
Yo no encuentro la forma de pasar parametros y ademas como cubro la forma de llamar a la funcion sin el CALL??
MGLSOFT
