Re: single-xt approach in the standard

On Tue, 17 Sep 2024 10:54:37 +0000, Ruvim wrote:

Do you think that the Forth standard should recognize the classic
single-xt approach as possible for implementing a standard Forth system?
>
The classic single-xt approach implies that only one execution token
(xt) is associated with a name token (nt), and only one name token is
associated with a word (a named Forth definition). And words whose
compilation semantics differ form default compilation semantics are
implemented as immediate words.
>
>
--
Ruvim

In my opinion the Forth standard should not care about implementation
details like how a header is organized ( single, dual xt or some other
way).
My system lxf/ntf was probably one of the first to introduce dual xts.
I saw this as a clean way to implement specific compilation behavior
for the native code generation. I started with the cmforth idea to have
separate compilation and interpretation wordlists. This worked well
until I also needed several different wordlists for other purposes.
From that came the idea of two xts.
The lxf64 I am working on now has instead a single xt. This will change
in the future when the native code generator is finished. The header
will then probable have 3 xts! at least logically.
- one to the bytecode
- one to interpreting code
- one for the compile-time code
The system compiles to bytecode ( a token threaded system ).
It runs very well on just the bytecode, only 5-10 times slower then lxf.
The bytecode is needed to give a well working inlining possibility.
The compile-time action will then be either to inline the bytecode or
compile a call to already compiled native code.
The interpreting code will be generated when the bytecode is compiled
and sent to the native code-generator that produces assembler source
that is feed into an external assembler.
The header will then store a pointer to the compiled interpreting code
the byte code will follow directly after the header and the compile
time action can be determined from flags in the header.
Looking back at the standard, in my opinion it was a mistake to
standardize the nt!  It would have been better to have
FIND-INTERPRET  instead of FIND-NAME NAME>INTERPRET  and
FIND-COMPILE  instead of FIND-NAME NAME>COMPILE.
That would have given more freedom to organize the internal header
structure.
BR
Peter Fälth