Re: [colorforth] Hello - and where to begin: Sourceless Programming
- Subject: Re: [colorforth] Hello - and where to begin: Sourceless Programming
- From: "Jeff Fox" <fox@xxxxxxxxxxxxxxxxxxx>
- Date: Tue, 22 Jan 2008 15:01:23 -0800 (PST)
>> dictionary of names but Chuck was the compiler.
>
> Threaded or machine code?
Subroutine threaded code I think. He would enter the first
code with some debugger or his own primitive tools, then
do the hex editor, the font editor, then the screen editor,
then the decompiler. The gui would put a graphic on the screen
and active a key table with 8 entries for 7 cursor and control
keys and a timeout. hitting a key might change modes and
load a new graphic and key table.
> I always thought a sourceless system using
> indirect threaded code would be a lot more practical than one using
> straight machine code, simply because the correspondence is already so
> close.
I understand. But that same one to one correspondence is a feature
of machineForth, subroutine threaded with inlined primitives is a
form of token threading if you think of the calls and primitives as
tokens. If you build an interpreter they become tokens but if
you build hardware it becomes native code.
> 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. he does this in colorforth also
when switching from green to yellow to green. a number left in
the yellow phrase will be compiled as a literal.
this was one of the things missing from sourceless programming.
you could decompile but would only the compiled literal and
it would just be a magic number. in real source the number
may be computed in yellow in a way that give it meaning so
it isn't just a magic number in the code.
> and {
> ... } to return the address of a chunk of code to execute later, and
> you have something with which any Jupiter ACE owner would be
> immediately familiar - that was also a sourceless system. (It had the
> fascinating property that comments would slow down execution, as the
> time to jump over the inlined text was greater than 0.)
>
> 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.
best wishes
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com