Re: [colorforth] DOES> How is colorForth different from other Forths?

["Samuel A. Falvo II" <kc5tja@xxxxxxxx>]

On Monday 22 December 2003 06:51 am, Jonah Thomas wrote:
> > How much do you value this correspondance? Is there some benefits to
> > use it in bytecode implementations for example?
>
> I'm not clear what Chuck will use in place of DOES> .  There might be

Chuck already presented what he uses in an earlier message in this 
thread.  In the simple case:

: handler ... ;
: word1 data-1 handler ;
: word2 data-2 handler ;
: word3 data-3 handler ;

etc

I demonstrate a more advanced case later in this e-mail.

> instructions from one name.  Traditional DOES> is more complicated
> than that, I don't think you can write it so it just compiles a short
> series of instructions.  But you might make macros that do <literal>

Sure you can.  That's how threaded DOES> implementations work.

DOES> performs two actions at a minimum, three at most:

1.  Compiles EXIT.  This ``terminates'' the former definition and 
``begins'' the sub-definition.

2.  Patches the last created word's CFA to point to the new 
sub-definition.

3.  If required, compiles code to place body address on the stack.

That's it.

Realistically speaking, the microprocessor hardware does 99% of this work 
when you invoke a subroutine.  This lets you do such neat tricks as 
this:

: array  r> + @ ;
: myArray1 array [ 0 , 1 , 2 , ...etc...

When array is called, it has its parameter not on the data stack, but on 
the *return stack*.  The return address of the subroutine call to array 
is the same address as where the data that we want to access is located.  
Consequently, we need r> to obtain that address.

(Hmm...I suppose I should be using pop instead of r> and push instead of 
>r; but I feel >r and r> are more descriptive names for what's going on, 
as you also push and pop data from the data stack too.  Besides, they 
take less space on the screen.)

This isn't as bad as it sounds, since 50% of the time when working with 
CREATE/DOES> constructed words, I have to >R the doggone address first, 
then massage the data, then R> it back.  So for a large class of words, 
having the body address left on the return stack to begin with actually 
helps code legibility (my opinion at least).

This is why ColorForth lacks an explicit CREATE/DOES> constructor 
wordset.  99% of the functionality of these two words are already 
present in the underlying hardware.  As ColorForth is a MachineForth 
dialect, it makes sense to exploit and expose the underlying hardware as 
much as feasible, rather than trying to emulate the "ideal" Forth 
microprocessor in software.

--
Samuel A. Falvo II


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