[ColorForth] Passing values from Compiletime to Runtime

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx>]

Dear ColorForth list readers:

In his 99 and 2000 presentations Chuck went into some detail
on his color token mechanism which used two lookup tables.
When he first mentioned it he said that two color change
tokens were not really visible unless you passed the cursor
"ring" over them.  Later he explained in some detail how
it shifted 4 bits and kept track of the last color, present
color, and new color when making a change.

However in his latest ColorForth he has simplied the mechanism
that he was using a couple of years ago.  The issue is mainly
literals and interpreted sequences as Terry has explained.

the idea is that is these things will compile the same code

: IT OLD [ BASE @ OFFSET @ + ] LITERAL ;

: IT OLD 12345 ;

_red IT _green OLD _black BASE @ OFFSET @ + _grey _green ;

_red IT _green OLD _grey 12345 _green ;

Something like that.   However one should note that the ColorForth
examples are closer to #H 12345 or #D 12345 in that they include
a prefix command that specifies a temporary number base for the
following number.  It should also be noted that in traditional
Forth the number is stored as a string and the temporary number
base is used at compile time to calculate the binary value that
gets compiled while the ColorForth does more at edit time and
less at compile time.  In ColorForth the prefix notation that 
it is HEX or DECIMAL (or whatever) is for the display of the
value, the value is stored and fetched in binary form in the
the source code at compile time and is not converted from
text to binary at compile time.  The idea is take advantage
of the fact that you know something about the code at
edit time and can store it in a more efficient way.

In Chuck's approach to Forth he used to talk about moving things 
from runtime to compile time.  Now he talks about trying to move
things from runtime back to compile time and from compile time
back to edit time and from edit time back to design time.  The
biggest advantages are things that get elimated at design time,
or at least done as early as possible.

Now the compile must pass values from compile time to runtime.  And
the traditional Forth mechanism is LIT which gets compiled by LITERAL.
The equivalent in MachineForth is the LIT opcode also known as # or n.
It is an immediate load to top of stack instruction in that
environment.

Terry has explained some reasoning behind having two color
change tokens in a sequence to simplify the literal 
implementation.  In addition there is the concept that
Chuck is now doing something like what a traditional
Forth compiler did in his editor with numbers and
compiling a LIT+number_base color token and a number field.
He has moved one function from compile to edit time to get
a faster and simpler compiler, more compact code representation,
and earlier error checking on the number field in the editor
instead of in the compiler.  This is part of his moving away
from byte oriented source representation to word packed
source representation.

Jeff Fox
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.ultratechnology.com