home .. forth .. colorforth mail list archive ..

Re: [colorforth] About a byte-sized colorforth


How the editor could process source?

The editor could have the same mechanism as the editor to handle definitions, using a sequential Index array to store definition addresses. But in this case it would be the real definition, the address pointing at the def token somewhere in memory. My display routine is written, but I wont post it here, it's straightforward. Don't have to use spaces (or graphical vesa drivers ;p) as the display routine empty the screen and draw from where its started, filling its Index with the definitions as it encouters them and rendering them on screen with the appropriate color when they are referenced, as a compilecall or jumpto token. The Cursor could negate the colors of the pointed word,
something like that.

When I decided to use 8 bit huffman, the ranges availables prompted me to chose 32 bytes bincopy from source to compiled code instead of putting a number (1,2,3 or 4 bytes, range of 4) on stack and then calling a macro word. But this token could be used to put small counted strings on the stack. For my compiler experiment purpose, the bin copy was ok, but now I see two inneficiencies: if the source is already loaded in ram, the bincopy becomes a useless move. But when code is downloaded from serial line, it's useful. Maybe that would be the star application.

Also, it's inneficient because most primitives "bincopy" stuff anyway. An example is the over definition. In my system's source, it's actually represented as "swapC70750FF365883C70466C7078F064747C3", where the "swap" definition is visually distinctive of the bincopy word.The catch is that the C0DE actually compiles 50FF36588F06 at [EDI] and increments it, the exact same job as bincopy. Maybe someone could help here, its been a while and I can't put the finger on the thing to do. Nothing urgent, I'm just curious if it could be done with added benefits in return.

To reuse the bincopy, I guess the compiler core (detokenizer) would mutate into an interpreter...Maybe it would be better, since actually I must unpack (detokenize) somwhere, run that middle code to compile somwhere and then run the application...
Now I'm sure there's something easier to do here.

Adam

Mark Slicker wrote:

On Wed, 9 Jul 2003, Samuel Falvo wrote:

What is the of advantage bincopy token over a number token? A number token
would compile code to push a literal on the stack.
A bincopy token would just compile a set of raw bytes into the dictionary.
It's up to the editor to determine how to render those values.  It seems like
it eliminates the need for DEADBEEF , FEEDFACE , 01234567 , 89ABCDEF ,
...etc...

This much is obvious. I mean the sum total advantage of bincopy over
number. Perhaps it is too early to say. This is why I wanted to avoid
criticism of Adam's system at this point. It is not fully worked out, so
it is difficult to tell what the impact of features will be on
application development.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com