[ColorForth] Passing values from Compiletime to Runtime
- Subject: [ColorForth] Passing values from Compiletime to Runtime
- From: "t" <loveall@xxxxxxxxx>
- Date: Wed, 2 May 2001 14:10:31 -0800
Dirk,
The correct example you provide is from the 4word implementation of Color
Forth. Chuck Moore's Color Forth probably adheres closer to your requested
changes. Not sure, because he described it's operation without supplying
code.
You have a point about two color tokens back to back, if what you are
concerned about is the readability of the source code. However, if your
concern is about how simple of an implementation the language is, then the
result is back-to-back colors.
The interpreter for 4word was made as simple as possible. This was done to
aid in understanding exactly how Color Forth operates. The better the
programmer understands the interpreter/compiler, the more effective the
programming.
I derived an implementation of Chuck's Color Forth. You can download it from
the link marked "Color Forth w/MASM source" at
http://www.users.qwest.net/~loveall/ModProg.htm
This is an implementation that behaves as you describe, i.e.
"[red] 1+ [green] 1 [grey] + [black] ;"
using your colors.
Chuck described using jump tables based upon the current color and previous
colors (a context sensitive interpreter/compiler). The implementation of the
color sensitive interpreter that I came up with, had seperate
interpret/compile mode definitions that were more complex and less obvious
as to how they operated.
Later, when implementing 4word, it became apparent that at the cost of
having back-to-back colors, the interpreter/compiler could be simplified.
This, I felt, was a worthwhile trade-off. It also forced me to keep in mind
the exact cost in additional memory for inline literals. Sometimes memory is
more significant than speed, and sometimes the reverse, but exactly what the
interpreter is doing is always present.
If the readability of the source code becomes significant enough, the means
to implement this change are available. However, during the writing of the
rest of the code in the 4word package, it never seemed to be a necessity.
Regards,
Terry Loveall
----- Original Message -----
From: "Dirk Heise" <dheise@xxxxxxxxxxx>
To: "ColorForth List Member" <ColorForth@xxxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 02, 2001 11:23 AM
Subject: [ColorForth] Passing values from Compiletime to Runtime
> Hi!
> I'm new on this list, so please excuse me if
> this has been discussed before... and let me introduce
> myself, i'm Dirk Heise from Braunschweig, Germany.
> During the last 20 years, i traveled from Basic to Forth
> to Pascal to C to C++ to Python to Forth, mainly.
> Though, at work, still using C++, a pity, but i don't
> have to program a lot anymore there, so that's fine.
>
> I have read only little about ColorForth by now. mainly
> the Fireside Chat on ultratechnology and the documentation
> of a Color Forth by Terry Loveall, and i haven't used it
> myself by now. So maybe i got things all wrong ;-)
>
> As i understand it, to do something like
> : 1+ 1 + ; ( classic Forth )
> you do something like
> [red] 1+ [green] 1 [blue] [grey] + [black] ;
> where red = define
> green = decimal number
> blue = compile literal
> grey = compile call
> black = execute
> I made up the color coding myself now... Don't have
> Terry's docs handy right now.
>
> So, what disturbs me is the blue color token that in
> my example compiles the literal (passes the value
> from compiletime to runtime), because two color tokens
> follow without a word in between.
>
> First, is my example correct? Would it have to look like this
> in ColorForth?
> Second, what do other people think of this double color
> token? I would like to get rid of it, my best idea
> so far would be to overload ">" to be an operator for
> this "value passing". I just dislike the idea of this
> rather invisible two-color thing and would like to
> replace it with something more visible.
>
> Of course, this would obfuscate some arithmetic
> expressions, but i would like to have a single-key
> operator because it's so frequently needed.
>
> Thinking a bit further, such an operator could be extended.
> Like, imagine the Forth is indirectly threaded (i hope
> that that is the correct term -- i mean like a Fig-Forth,
> using byte codes), the bytecodes for the example above
> would be
> lit 1 +
> ; and as the sequence
> lit n +
> is one of the more frequent ones, one could create a
> runtime word "lit+" that could be used like this:
> lit+ n
> which would be faster and smaller. To tell the compiler
> to use it, one could now define a compiler word
> >+
> that combines the effect of my imaginary ">" (or the
> two-color sequence) and compiling a call to +. Thus,
> 1 >+
> would do the same as
> 1 > +
> but create slightly better code.
>
> What are your opinions? Did this make sense?
>
> Dirk Heise
> dheise@xxxxxxxxxxx
> <<If you want it done right, you gotta do it yourself.>>
>
> ------------------------
>
> 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
>
>
------------------------
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