| Message ID | 20240123093801.743733-1-kconsul@linux.vnet.ibm.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | slof/engine.in: remove the "COMPILE" keyword | expand |
On 2024-01-23 10:43:48, Thomas Huth wrote: > On 23/01/2024 10.38, Kautuk Consul wrote: > > "COMPILE" isn't being used anywhere in the Forth code as it is > > currently only being used for "+COMP" and "-COMP" keywords. > > Remove this keyword definition and use the standard "DOTICK <word> COMPILE," > > mechanism as is being used by the rest of the compiler. > > "compile" is defined by IEEE 1275, so I doubt that we should remove it? > > Thomas Oh yes it is. So we can keep that keyword for maintaining the standard. But can we at least use DOTICK <word> COMPILE, for +COMP and -COMP as that seems to be more efficient than utilizing the return stack in the "COMPILE" does ? > >
On 2024-01-23 11:00:31, Thomas Huth wrote: > On 23/01/2024 10.48, Kautuk Consul wrote: > > On 2024-01-23 10:43:48, Thomas Huth wrote: > > > On 23/01/2024 10.38, Kautuk Consul wrote: > > > > "COMPILE" isn't being used anywhere in the Forth code as it is > > > > currently only being used for "+COMP" and "-COMP" keywords. > > > > Remove this keyword definition and use the standard "DOTICK <word> COMPILE," > > > > mechanism as is being used by the rest of the compiler. > > > > > > "compile" is defined by IEEE 1275, so I doubt that we should remove it? > > > > > > Thomas > > Oh yes it is. So we can keep that keyword for maintaining the standard. > > But can we at least use DOTICK <word> COMPILE, for +COMP and -COMP > > as that seems to be more efficient than utilizing the return stack in > > the "COMPILE" does ? > > Sounds like a reasonable optimization to me at a quick glance. But maybe > Segher could also comment on this, he's more experienced in this SLOF engine > stuff than anybody else. 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. 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.
Hi Segher, On 2024-01-23 16:11:14, Kautuk Consul wrote: > On 2024-01-23 11:00:31, Thomas Huth wrote: > > On 23/01/2024 10.48, Kautuk Consul wrote: > > > On 2024-01-23 10:43:48, Thomas Huth wrote: > > > > On 23/01/2024 10.38, Kautuk Consul wrote: > > > > > "COMPILE" isn't being used anywhere in the Forth code as it is > > > > > currently only being used for "+COMP" and "-COMP" keywords. > > > > > Remove this keyword definition and use the standard "DOTICK <word> COMPILE," > > > > > mechanism as is being used by the rest of the compiler. > > > > > > > > "compile" is defined by IEEE 1275, so I doubt that we should remove it? > > > > > > > > Thomas > > > Oh yes it is. So we can keep that keyword for maintaining the standard. > > > But can we at least use DOTICK <word> COMPILE, for +COMP and -COMP > > > as that seems to be more efficient than utilizing the return stack in > > > the "COMPILE" does ? > > > > Sounds like a reasonable optimization to me at a quick glance. But maybe > > Segher could also comment on this, he's more experienced in this SLOF engine > > stuff than anybody else. > 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. > 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. Any comments on this ? It's been a week or so. :-)
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 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
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
Hi, One more think I want to say in the discussion below: On 2024-02-01 10:42:11, Kautuk Consul wrote: > 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. Just to clarify (although you already know it): "DOTICK DOCOL COMPILE," will work the same as "COMPILE DOCOL", only it will work faster as the return stack will not be used.
On Thu, Feb 01, 2024 at 11:02:29AM +0530, Kautuk Consul wrote: > Just to clarify (although you already know it): "DOTICK DOCOL COMPILE," > will work the same as "COMPILE DOCOL", only it will work faster as > the return stack will not be used. Of course it does use the return stack. Every colon definition does. Things like this (manual inlining) are counterproductive, and thus only wanted for cases that really matter a lot. Like making the engine 3x faster on average. Not 0.0003% faster. There always is a tiny loss from abstraction. The compiler can try to reduce that. But the programmer should not! Clear, readable, idiomatic code is much more important than machine cycles. Optimise for the human first, not the machine. Segher
diff --git a/slof/engine.in b/slof/engine.in index 59e82f1..cd287d6 100644 --- a/slof/engine.in +++ b/slof/engine.in @@ -419,11 +419,9 @@ imm(Z" S" 2DUP + 0 SWAP C! DROP) imm(." STATE @ 0BRANCH(5) S" DOTICK TYPE COMPILE, EXIT LIT('"') PARSE TYPE) 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 EXIT COMPILE, THERE @ DOTO HERE COMP-BUFFER EXECUTE) // Structure words. col(RESOLVE-ORIG HERE OVER CELL+ - SWAP !)
"COMPILE" isn't being used anywhere in the Forth code as it is currently only being used for "+COMP" and "-COMP" keywords. Remove this keyword definition and use the standard "DOTICK <word> COMPILE," mechanism as is being used by the rest of the compiler. Signed-off-by: Kautuk Consul <kconsul@linux.vnet.ibm.com> --- slof/engine.in | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)