Threading in C (Re: RRe: What's so good about FORTH?

[rb at cci632.UUCP]

In article <6993 at boring.mcvax.UUCP> lambert at boring.uucp (Lambert Meertens) writes:
>In article <255 at myrias.UUCP> mj at myrias.UUCP (Michal Jaegermann) writes:
>
>> The fact that Forth is "threaded" is not a part of a language definition but
>> side-effect of the most popular implementation method.  [...]  The method
>> is far from beeing unique to Forth and there are some Forth implementations
>> which are not exactly "threaded".  [...]

Often this is called subroutine threaded language.  It is considered "legal"
in Forth 83.

>How else can you implement threading if C is used as the implementation
>language?

>    goto *(IC++)
	
>Are there other ideas on implementing threading in C?

There seems to be a little confusion about threading here.  All that is
*really* required for threading is a parameter stack that is separate
from the program/return stack.

As far as getting indirect threading (not required, but possible),
all that is required is to have a very large "array of pointers to
funtions returning void or int".  This may be necessary if your
machine insists on keeping code and data areas separate.  This is
the technique used in Kernigan/Pikes "Hoc" language after about
revision 4.  Nice simple threading machinism without too much fuss.
As a matter of fact, Hoc would make a very nice "interpret or compile"
language.

int (dict [HUGE])();	/* this defines the dictionary area */

dict(IC++)();		/* this defines the "inner loop interpreter" */

It is also possible to just use subroutine calls and append parens to
each word.  If the compiler is smart enough to not try to save a lot
of context on each call, this can be very cheap.

In either case, a separate parameter stack of ints or longs provides
a nice effective threading.  This technique is even described in the
K&R C programmers manual.

You don't have to have forth to get the benifits of threaded code.