[SLOF] [PATCH] slof/engine.in: remove the "COMPILE" keyword

[Kautuk Consul]

Hi,

One small rectification in my previous email.

On 2024-02-01 10:40:00, Kautuk Consul wrote:
> Hi Segher,
> 
> On 2024-01-31 10:11:05, Segher Boessenkool wrote:
> > On Tue, Jan 23, 2024 at 04:11:09PM +0530, Kautuk Consul wrote:
> > > So, 2 questions for Segher:
> > > i)	Can we use the standard DOTICK DOCOL COMPILE, and DOTICK SEMICOLON
> > > COMPILE, method for +COMP and -COMP respectively ? That seems to be more
> > > efficient as that doesn't use the return stack.
> > 
> > No, the standard requires the word COMPILE to exist.  It is a standard
> > Forth word, historical (it isn't part of ANS Forth).
> 
> Yes, I do understand that now.
> But I am just proposing that we use "DOTICK DOCOL COMPILE," instead of
> "COMPILE DOCOL" in "+COMP" so that the compiler doesn't have
> to use the return stack as it is not required in "+COMP". Same thing goes for -COMP.
> It's a minor performance improvement, but I spotted this while reviewing
> the code so I decided to send this patch.
> > 
> > In compiled code of course you will see what is compiled by the
> > compiler, not the source code.  COMPILE is compilation-only word, so you
> > do not see it in command scripts even.  In very old Forth
> > implementations it would be simply compiled like anything, so
> > "COMPILE DUP" would end up as two cells with the addresses of "COMPILE"
> > and "DUP" in the generated (indirect-threaded or direct-threaded) code,
> > and at runtime the COMPILE would get the next cell and plop it into the
> > currently compiling definition.  But not anymore: this cannot work for
> > more modern implementations, better optimising implementations; we now
> > have POSTPONE instead of COMPILE (and [COMPILE] , in ye olde days the
> > programmer had to know which words were immediate words).
> > 
> > engine.in is compiled code (well almost, not yet fixed to any absolute
> > address and stuff).
> > 
> > > ii)	Instead of EXIT used in -COMP can we use SEMICOLON instead to
> > > compile into HERE ? That seems to be in line with how the col() macro
> > > is defined and gives better information to the reader of this code that
> > > the compiler is trying to generate the same "DOCOL <forth words> SEMICOLON"
> > > format of defining subroutines.
> > 
> > I have no idea what you mean, sorry.  Propose a patch, and say why that
> > would be better?
> What I mean is that the col() macro is defined by:
> #define col(_xt, _def...) def(DOCOL _def SEMICOLON)
> 
> +COMP and -COMP are defined by:
> 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)

The lines actually are as follows:
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)


> 
> The above 2 lines compile the same "DOCOL _def SEMICOLON" type of
> subroutines for IF, WHILE, CASE, ENDCASE, BEGIN, UNTIL, etc. when they
> are not defined in any coloon definition of a FORTH subroutine.
> 
> But, the way +COMP and -COMP are currently working is that they are
> compiling the following code into HERE:
> DOCOL _def EXIT
> 
> Instead of compiling the EXIT Forth routine in -COMP I will try to make
> the compiler compile the following format for IF, WHILE, CASE, ENDCASE,
> BEGIN, UNTIL, etc. :
> DOCOL _def SEMICOLON
> 
> I can propose a patch for both the "COMPILE," as well as this SEMICOLON
> idea together once you are okay with my suggestions.
> 
> Thanks!
> 
> > 
> > 
> > Segher