On Mon, Feb 12, 2024 at 02:58:46PM +0530, Kautuk Consul wrote:
> Hi Segher/Thomas,
>
> On 2024-02-02 00:15:48, Kautuk Consul wrote:
> > Use the standard "DOTICK <word> COMPILE," mechanism in +COMP and -COMP
> > as is being used by the rest of the compiler.
> > Also use "SEMICOLON" instead of "EXIT" to compile into HERE in -COMP
> > as that is more informative as it mirrors the way the col() macro defines
> > a colon definition.
> >
> > Signed-off-by: Kautuk Consul <kconsul@xxxxxxxxxxxxxxxxxx>
> > ---
> > slof/engine.in | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/slof/engine.in b/slof/engine.in
> > index 59e82f1..fa4d82e 100644
> > --- a/slof/engine.in
> > +++ b/slof/engine.in
> > @@ -422,8 +422,8 @@ imm(.( LIT(')') PARSE TYPE)
> > col(COMPILE R> CELL+ DUP @ COMPILE, >R)
> >
> > var(THERE 0)
> > -col(+COMP STATE @ 1 STATE +! 0BRANCH(1) EXIT HERE THERE ! COMP-BUFFER DOTO HERE COMPILE DOCOL)
> > -col(-COMP -1 STATE +! STATE @ 0BRANCH(1) EXIT COMPILE EXIT THERE @ DOTO HERE COMP-BUFFER EXECUTE)
> > +col(+COMP STATE @ 1 STATE +! 0BRANCH(1) EXIT HERE THERE ! COMP-BUFFER DOTO HERE DOTICK DOCOL COMPILE,)
> > +col(-COMP -1 STATE +! STATE @ 0BRANCH(1) EXIT DOTICK SEMICOLON COMPILE, THERE @ DOTO HERE COMP-BUFFER EXECUTE)
>
> What do you think about the above changes ?
> Are there any more changes I could do to this patch ?
> Or if you want to reject can you tell me why exactly ?
I think both changes are bad. They reduce abstraction, for no reason at
all.
If you think the compiler should inline more, or do better optimisations
even, work on *that*, don't do one unimportant case of it manually.
I never made the indirect threading engine in Paflof faster, because it
was plenty fast already. In SLOF, almost everything is compiled at
runtime, and if it is important to speed that up there are some well-
known usual caching tricks to make things *factors* faster. The main
focus points for SLOF were to have an engine that is easily adapted for
different purposes (and it was! Ask me about it :-) ), and to have
things using it as debuggable as possible (you really need some hardware
debugging thing to make it real easy; I had one back then. You need to
be able to look at all memory state after a stop (a crash, perhaps), and
seeing all CPU registers is useful as well.
If you want to improve engine.in, get rid of it completely? Make the
whol thing cross-compile perhaps. Everything from source code. The
engine.in thing is essentially an already compiled thing (but not
relocated yet, not fixed to some address), which is still in mostly
obvious 1-1 correspondence to it source code, which can be easily
"uncompiled" as well. Like:
col(+COMP STATE @ 1 STATE +! 0BRANCH(1) EXIT HERE THERE ! COMP-BUFFER DOTO HERE COMPILE DOCOL)
col(-COMP -1 STATE +! STATE @ 0BRANCH(1) EXIT COMPILE EXIT THERE @ DOTO HERE COMP-BUFFER EXECUTE)
: +comp ( -- )
state @ 1 state +! IF exit THEN
here there !
comp-buffer to here
compile docol ;
: -comp ( -- )
-1 state +!
state @ IF exit THEN
compile exit
there @ to here
comp-buffer execute ;
"['] semicolon compile," is not something a user would ever write. A
user would write "compile exit". It is standard Forth, it works
anywhere. It is much more idiomatic..
Segher
