Re: [colorforth] About a byte-sized colorforth

[Adam Marquis <adam.marquis@xxxxxxxxxxxx>]

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