Re: Hello - and where to begin: Sourceless Programming

On 22/01/2008, Jeff Fox <[email protected]> wrote:
> >> dictionary of names but Chuck was the compiler.
> >
> > Threaded or machine code?
>
> Subroutine threaded code I think.

Ah - I can see that being a little more difficult to decompile than
indirect threaded code (particularly on an x86, where all jumps are
relative).

> I understand. But that same one to one correspondence is a feature
> of machineForth

Not quite - you still have to worry about jump destinations (where to
put THEN). Whereas indirect threaded code can roll that up into a
higher level primitive, for example one that calls one of two words
depending on the flag on the top of the stack, or the Y combinator.

And then once you've got that far, indirect threading lets you change
what the primitive does, so that rather than executing its code, it's
compiling it into the code area - instant JIT compilation!

> > Add [ ... ] to memoise a constant (so that it only executes the
> > first time it's run, and thereafter just returns the result),
>
> Chuck compiles a constant that when compiled compiles a literal
> with the value of the constant.

I know, I read the description. I'm talking about an approach to doing
it in threaded code which preserves the calculation you started with,
which I remember being one of Chuck's issues with sourceless
programming. Basically, you'd compile the word as before, but it'd
reserve an extra cell at PFA, and its CFA would point to a chunk of
code which executes the word at PFA+1, stores the TOS at PFA, and
changes the CFA to that of CONSTANT. Constant optimisation in a
sourceless system, but without losing the semantic value of the
constant.

And not only that - if we go with the JIT idea, where executing
threaded code actually compiles native code, we can execute the
bracketed code and just compile the result as a literal.

> > In fact, colorForth source more or less IS threaded code - just token
> > threaded, rather than indirect threaded, and with a number of possible
> > ways of interpreting each token - and the inner interpreter has become
> > the outer interpreter...
>
> When targeting machineForth hardware the approach is native code.
> Otherwise, as you say, it is a form of token threading.

You miss my meaning - what I mean is that a BLOCK in colorForth is
effectively a chunk of threaded code which, when executed, compiles a
chunk of native code. Token threaded, because the code cells aren't
actually pointers to other bits of threaded code; and slightly unusual
in that the CFAs are included with the tokens rather than the
definitions (and there are only 16 possible CFA values) - but threaded
code, nonetheless.

Regards
Gwenhwyfaer