Krishna Myneni wrote:
> To do that properly, I want to go to a dual-xt system and
> avoid explicit STATE-dependence (which has other benefits we've
> discussed in the past). That's a bigger project for later.

Forge ahead. Having worked with both versions (state-smart and
dual-xt), I have to say that the investment in converting a
well-running, debugged Forth system to dual-xt only pays off
if you "POSTPONE like crazy" or are in the habit of writing DSLs.
Otherwise, state-smartness can be an itch, but is not bad per se.

On 12/18/23 07:05, Krishna Myneni wrote:
....

I have pushed these changes in kForth-64 into the main branch at github:

1. make FSL matrix addressing word }} an intrinsic word for higher
efficiency.

2. update the fsl-util.4th to only load the Forth source version of }}
if it is undefined.

The test code fsl-tester.4th (in forth-src/fsl/) may be used to verify
that FSL code runs correctly with the faster version of }}.

These changes will also appear in kForth-32 and in kForth-Win32, after a
short period of testing.

--
Krishna

On 18.12.2023 00:48, dxf wrote:
> On 16/12/2023 6:45 pm, Anton Ertl wrote:
>> ... And Chuck Moore and others who do not use locals do not
>> practice what Jeff Fox preached. They just use VARIABLEs instead
>> of locals.
>

Anno Domini 1999 A.C., the great unfallible

> Moore

uttered the eternal thruth:

> has said:
>
> "Don't use local variables [...] It's bad. It's wrong."

Thou shalt not... etc.

>
> <https://www.ultratechnology.com/1xforth.htm>
>

Sorry, I'm bearing all the respect that Charles Moore deserves, but with
all his statements about Forth, he never intended to proclaim universal
truths, but he described, what worked best for himself.

Undoubtlessly, he discovered (as he himself describes it) Forth, and had
great influence on the language basics that carry forth until today.
Some of his recommended practices (factor, factor, factor; don't
optimize prematurely; hooks are unecessary when in anticipation of some
still unknown future requirement; and many more), and his general
approach to Forth programming style (e.g. advocating short, consise
definitions, and if you can't track the stack values in your head,
you've got to factor something out) do still hold today, and not
exclusively for stack-oriented programming languages only.

> If he's merely using VARIABLEs where locals would otherwise be used
> that's worth investigating. Unfortunately I'm not aware of any
> substantive code by Moore in the public domain to test the
> proposition.

CMForth sources (https://github.com/ForthHub/cmFORTH), the contents of
the ArrayForth default block file (download at
https://www.greenarraychips.com/home/support/download-03d.php)
some snippets from his former website colorforth.com (mirrored at
https://colorforth.github.io/) ...

Regards,
--
Bernd Linsel

On 12/18/23 07:32, minforth wrote:
> Krishna Myneni wrote:
>> To do that properly, I want to go to a dual-xt system and avoid
>> explicit STATE-dependence (which has other benefits we've discussed in
>> the past). That's a bigger project for later.
>
> Forge ahead. Having worked with both versions (state-smart and
> dual-xt), I have to say that the investment in converting a
> well-running, debugged Forth system to dual-xt only pays off
> if you "POSTPONE like crazy" or are in the habit of writing DSLs.
>
> Otherwise, state-smartness can be an itch, but is not bad per se.

It's a tradeoff between having a utilitarian Forth system to compute
various tasks efficiently, versus having a Forth system which provides
tools for exploratory programming such as DSLs and introspection
capabilities.

For larger software projects, being able to write introspection tools
with the underlying language have demonstrable utility (see past
discussion on making word dependency trees). Dual xt systems with a
couple of support words are one way to allow for this.

Balancing these two goals without breaking an actively used Forth system
requires a more cautious approach. And, of course, time is limited.

--
Krishna

On 12/18/23 07:37, Krishna Myneni wrote:
> On 12/18/23 07:05, Krishna Myneni wrote:
> ...
>
> I have pushed these changes in kForth-64 into the main branch at github:
>
> 1. make FSL matrix addressing word }} an intrinsic word for higher
> efficiency.
>
> 2. update the fsl-util.4th to only load the Forth source version of }}
> if it is undefined.
>
> The test code fsl-tester.4th (in forth-src/fsl/) may be used to verify
> that FSL code runs correctly with the faster version of }}.
>
> These changes will also appear in kForth-32 and in kForth-Win32, after a
> short period of testing.
>

I also introduced the word "*+" in the last commit in kForth-64.

*+ ( a b c -- n ) \ n = a*b + c

Note that *+ is not the same as the sequence "* +", It has the
equivalent effect of the following:

-ROT * +
>R * R> +

*+ is similar to the Forth standard word, "*/". Such ternary operators
reduce stack juggling and make code more readable. As an example, the
custom floating point array words from pde1.4th can now be recoded from

: ]]F@ ( a row col -- r ) >r GRIDSIZE * r> + floats + f@ ;
: ]]F! ( r a row col -- ) >r GRIDSIZE * r> + floats + f! ;

to

: ]]F@ ( a row col -- r ) GRIDSIZE swap *+ floats + f@ ;
: ]]F! ( r a row col -- ) GRIDSIZE swap *+ floats + f! ;

It simplifies the code and increases the performance of SOLVE by about 10%.

I expect the floating point version, F*+, to be equally, if not more
useful for improving readability of fp code and increasing efficiency.

F*+ ( F: r1 r2 r3 -- r ) \ r = r1*r2 + r3

F*+ provides a intrinsic scalar linear transformation. I have not yet
added this word.

--
Krishna

--
Krishna

On 19/12/2023 6:46 am, Bernd Linsel wrote:
> ...
> Sorry, I'm bearing all the respect that Charles Moore deserves, but with
> all his statements about Forth, he never intended to proclaim universal
> truths, but he described, what worked best for himself.

If Moore stated universal truths it wasn't for self-aggrandizement. The
parallel I would draw is Diogenes. Few would suggest Diogenes did what
was best for himself - not by society's standards anyhow.

What is best for myself? As part of humanity I imagine it is pursuing
pleasure and avoiding fear. Carrot and stick. Locals, as well as being
easy, will protect me from all manner of nasties. So that is the human
reaction. As with Diogenes, Moore saw the mess humans had created for
themselves and sought a way out. To dismantle the layers of conveniences
and protections without creating new ones demanded intelligence - not
reaction.

Apologies for the philosophy but after all these decades I doubt I'd
still be involved with Forth if it weren't for the universal truths :)

mhx wrote:
> minforth wrote:
> [..]
>> In addition, the normal integer and fp data stacks
>> are full enough with other things, so the mstack is also useful for clearer code.

> It probably comes as no surprise that I find locals to be a perfect solution
> for that.

Yes and no, depending on whether you are working with global matrices à la FSL
or with a stack of matrix pointers, where you can DUP and DROP matrices.
Copy-on-write is a big plus here, otherwise you have to manage (temporary)
matrix copies and perhaps free the data yourself.

With copy-on-write in the background, matrix locals are easy.
OTOH I don't see much advantage in using matrix locals for dealing with
global FSL matrices.

minforth wrote:

> mhx wrote:
> OTOH I don't see much advantage in using matrix locals for dealing with
> global FSL matrices.

I don't use the FSL for serious work but I stuck with its basic interface
words. Maybe I'll change that when it comes to a 2nd version of iForth
or iSPICE.

-marcel

mhx wrote:
> I don't use the FSL for serious work but I stuck with its basic interface
> words. Maybe I'll change that when it comes to a 2nd version of iForth
> or iSPICE.

"Don't fix it if it ain't broke" ;-)

I'd rather invest in more readability i.e. easy transformation from usual
Matlab notation to Forth. A simple example:
Matlab: (v'Av) where A is a matrix and v' is the transposed vector of v
Forth postfix:
> .. v' A m* v m* 0> IF ...

A suffix recogniser comes in handy with coding linear algebra.

minforth wrote:

> I'd rather invest in more readability i.e. easy transformation from usual
> Matlab notation to Forth. A simple example:
> Matlab: (v'Av) where A is a matrix and v' is the transposed vector of v
> Forth postfix:
>> .. v' A m* v m* 0> IF ...

I have to say

FORTH> 2 2 FLOAT MATRIX a{{
FORTH> 1e 2e 3e 4e a{{ #=> ok
FORTH> a{{ }}print
1.000000e+0000 2.000000e+0000
3.000000e+0000 4.000000e+0000 ok
FORTH> a{{ 1 =rowget a{{ a{{ 1 =colget =mat* swap =mat* }}print
3.000000e+0001 4.000000e+0001
6.600000e+0001 8.800000e+0001 ok
FORTH> a{{ }}print
1.000000e+0000 2.000000e+0000
3.000000e+0000 4.000000e+0000 ok

But I also have XOPG:

: test1 LET a = b*c-3.17e-5/TANH(w)+ABS(x): CR LET. a: ;
LET w = 1.e-3: LET x = -2.5: CR CR test1 -- 2.4682999894333340377777106878373968247191492

0-VALUE GVAL a 0-VALUE GVAL b 0-VALUE GVAL c
0-VALUE GVAL disc ( Used for discriminant )
: quadraticroot ( F: a b c -- y1 y2 )
TO c TO b TO a Pickup coefficients.
LET disc=SQRT(b*b-4*a*c): Set discriminant.
LET ((-b+disc)/(2*a),(-b-disc)/(2*a)): Put values on f-stack.
; ( x*x-3*x+2=0 ) LET quadratic root (1,-3, 2) :
CR .PRINT CR .PRINT -- prints 1 2
( goldenratio ) CR LET. MAX(quadra ticroot (1,-1,-1)): -- 1.6180339887498948482045868343656381177203

-marcel

mhx wrote:

> minforth wrote:

>> I'd rather invest in more readability i.e. easy transformation from usual
>> Matlab notation to Forth. A simple example:
>> Matlab: (v'Av) where A is a matrix and v' is the transposed vector of v
>> Forth postfix:
>>> .. v' A m* v m* 0> IF ...

> I have to say

> FORTH> 2 2 FLOAT MATRIX a{{
> FORTH> 1e 2e 3e 4e a{{ #=> ok
> FORTH> a{{ }}print
> 1.000000e+0000 2.000000e+0000
> 3.000000e+0000 4.000000e+0000 ok
> FORTH> a{{ 1 =rowget a{{ a{{ 1 =colget =mat* swap =mat* }}print
> 3.000000e+0001 4.000000e+0001
> 6.600000e+0001 8.800000e+0001 ok
> FORTH> a{{ }}print
> 1.000000e+0000 2.000000e+0000
> 3.000000e+0000 4.000000e+0000 ok

> But I also have XOPG:

> : test1 LET a = b*c-3.17e-5/TANH(w)+ABS(x): CR LET. a: ;
> LET w = 1.e-3: LET x = -2.5: CR CR test1 -- 2.4682999894333340377777106878373968247191492

> 0-VALUE GVAL a 0-VALUE GVAL b 0-VALUE GVAL c
> 0-VALUE GVAL disc ( Used for discriminant )
> : quadraticroot ( F: a b c -- y1 y2 )
> TO c TO b TO a Pickup coefficients.
> LET disc=SQRT(b*b-4*a*c): Set discriminant.
> LET ((-b+disc)/(2*a),(-b-disc)/(2*a)): Put values on f-stack.
> ;
> ( x*x-3*x+2=0 ) LET quadratic root (1,-3, 2) :
> CR .PRINT CR .PRINT -- prints 1 2
> ( goldenratio ) CR LET. MAX(quadra ticroot (1,-1,-1)): -- 1.6180339887498948482045868343656381177203

Great! Some of it looks like a more evolved ftran à la Julian Noble.

The matrix notation is a bit special, but when it works for you, okay.
I'd start with your example perhaps this way
> #[ 1 2 ; 3 4 ] :=> A ok parse matrix elements, create A and fill it
> A #. read A and print
[ 1. 2.
3. 4. ] ok
> A' #. read A, transpose (but don't change A) and print
[ 1. 3.
2. 4. ] ok
et cetera

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>But, I want }} to do the size-specific compilation,
>eventually. To do that properly, I want to go to a dual-xt system and
>avoid explicit STATE-dependence (which has other benefits we've
>discussed in the past).

Avoiding STATE is a good idea. However, what you have in mind seems
to be an optimization, not something like S". Dual-xt words are good
for stuff like S"; you can use them for optimization, but the
intelligent COMPILE, is better for that.

Gforth has had INTERPRET/COMPILE: (for defining a dual-xt word) for a
quarter-century and has 9 uses of that in its image, none of them for
optimizing (not even before we had SET-OPTIMIZER).

Gforth has had SET-OPTIMIZER (for specifying what the intelligent
COMPILE, does for a word) for less than a decade, and by now we have
the following numbers of uses of SET-OPTIMIZER and related words in
the image:

23 SET-OPTIMIZER
10 OPT:
13 OPTIMIZES
26 FOLDS

where FOLDS can be and is used to specify the optimization of multiple
words, in particular:

' fold1-0 folds drop
' fold1-1 folds invert abs negate >pow2
' fold1-1 folds 1+ 1- 2* 2/ cells cell/ cell+ cell-
' fold1-1 folds floats sfloats dfloats float+
' fold1-1 folds float/ sfloat/ dfloat/
' fold1-1 folds c>s w>s l>s w>< l>< x><
' fold1-1 folds wcwidth
' fold1-1 folds 0> 0= 0<
' fold1-2 folds dup s>d
' fold2-0 folds 2drop
' fold2-1 folds * and or xor
' fold2-1 folds min max umin umax
' fold2-1 folds nip
' fold2-1 folds rshift lshift arshift rol ror
' fold2-1 folds = > >= < <= u> u>= u< u<=
' fold2-1 folds d0> d0< d0=
' fold2-1 folds /s mods
' fold2-2 folds m* um* swap d2* /modf /mods u/mod bounds
' fold2-3 folds over tuck
' fold3-1 folds within select mux */f */s u*/
' fold3-2 folds um/mod fm/mod sm/rem du/mod */modf */mods u*/mod
' fold3-3 folds rot -rot
' fold4-1 folds d= d> d>= d< d<= du> du>= du< du<=
' fold4-2 folds d+ d- 2nip
' fold4-4 folds 2swap
' opt+- folds + -

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 12/19/23 10:43, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> But, I want }} to do the size-specific compilation,
>> eventually. To do that properly, I want to go to a dual-xt system and
>> avoid explicit STATE-dependence (which has other benefits we've
>> discussed in the past).
>
> Avoiding STATE is a good idea. However, what you have in mind seems
> to be an optimization, not something like S". Dual-xt words are good
> for stuff like S"; you can use them for optimization, but the
> intelligent COMPILE, is better for that.
>

We had a discussion about this earlier, and I did not like the design of
SET-OPTIMIZER changing the behavior of COMPILE, . I don't see the
drawback of changing the xt for compilation state as a method of
optimization. Why add extra complexity with SET-OPTIMIZER when you don't
have to?

--
Krishna

> mhx wrote:
>> 0-VALUE GVAL a 0-VALUE GVAL b 0-VALUE GVAL c
>> 0-VALUE GVAL disc ( Used for discriminant )
>> : quadraticroot ( F: a b c -- y1 y2 )
>> TO c TO b TO a Pickup coefficients.
>> LET disc=SQRT(b*b-4*a*c): Set discriminant.
>> LET ((-b+disc)/(2*a),(-b-disc)/(2*a)): Put values on f-stack.
>> ;

If I had your formula parser that would be here perhaps
: QUADRATICROOT { f: a b c | d == y1 y2 }
2.0 *to a
let d = sqrt(fma(b,b,-2*a*c))
let y1 = (-b+d)/a
let y2 = (-b-d)/a ;

minforth wrote:

>> mhx wrote:
>>> 0-VALUE GVAL a 0-VALUE GVAL b 0-VALUE GVAL c
>>> 0-VALUE GVAL disc ( Used for discriminant )
>>> : quadraticroot ( F: a b c -- y1 y2 )
>>> TO c TO b TO a Pickup coefficients.
>>> LET disc=SQRT(b*b-4*a*c): Set discriminant.
>>> LET ((-b+disc)/(2*a),(-b-disc)/(2*a)): Put values on f-stack.
>>> ;

> If I had your formula parser that would be here perhaps
> : QUADRATICROOT { f: a b c | d == y1 y2 }
> 2.0 *to a
> let d = sqrt(fma(b,b,-2*a*c))
> let y1 = (-b+d)/a
> let y2 = (-b-d)/a ;

Or with Noble's ftran and ANS locals (extended for fp-numbers)
: QUADROOT {: F: a b c | d -- y1 y2 :}
ft" sqrt(b*b-4*a*c)" to d
ft" (-b+d)/(2*a)" \ y1
ft" (-b-d)/(2*a)" ; \ y1 y2
IOW it is only a matter of personal preference for readability.

Concerning the topic of this thread, the interesting question is
whether the formula parser (infix to postfix translator) can be
extended to work with mixed matrix and fp scalar types.

Exemplary cases to be considered: matrix multiplication is not
commutative, and symbols could be overloaded e.g. A*b means
different things depending on which element is scalar or a matrix.

minforth wrote:

>> mhx wrote:
>>> 0-VALUE GVAL a 0-VALUE GVAL b 0-VALUE GVAL c
>>> 0-VALUE GVAL disc ( Used for discriminant )
>>> : quadraticroot ( F: a b c -- y1 y2 )
>>> TO c TO b TO a Pickup coefficients.
>>> LET disc=SQRT(b*b-4*a*c): Set discriminant.
>>> LET ((-b+disc)/(2*a),(-b-disc)/(2*a)): Put values on f-stack.
>>> ;

> If I had your formula parser that would be here perhaps
> : QUADRATICROOT { f: a b c | d == y1 y2 }
> 2.0 *to a
> let d = sqrt(fma(b,b,-2*a*c))
> let y1 = (-b+d)/a
> let y2 = (-b-d)/a ;

Yes, of course :--) However, my XOPG works with any type
variable, from bytes up to arbitrary-precision floats (here
the output for 64-bit FP is shown). Although elegant (for
some), adding arbitrary precision floats to local variables
is too much, even for a bricklayer like me. Hence the GVAL
global values.

When you have arbitrary precision, it is dangerous
to write something like "2.1 TO a", because 2.1e with the
extended double precision of the interpreter may not round
to exactly the 2.1 needed by, say, a 2048-bit arbitrary
precision number. This can create very subtle bugs.

-marcel

Krishna Myneni wrote:

> On 12/19/23 10:43, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> But, I want }} to do the size-specific compilation,
>>> eventually. To do that properly, I want to go to a dual-xt system and
>>> avoid explicit STATE-dependence (which has other benefits we've
>>> discussed in the past).
>>
>> Avoiding STATE is a good idea. However, what you have in mind seems
>> to be an optimization, not something like S". Dual-xt words are good
>> for stuff like S"; you can use them for optimization, but the
>> intelligent COMPILE, is better for that.
>>

> We had a discussion about this earlier, and I did not like the design of
> SET-OPTIMIZER changing the behavior of COMPILE, . I don't see the
> drawback of changing the xt for compilation state as a method of
> optimization. Why add extra complexity with SET-OPTIMIZER when you don't
> have to?

> --
> Krishna

LXF has from the beginning used the compiling XT also for optimization
(code generation). COMPILE, just compiles a call to the XT.
This works perfectly well and is easy to implement.
LXF has about 400 words that generate code while compiling.

BR
Peter

On 12/20/23 11:58, PMF wrote:
> Krishna Myneni wrote:
>
>> On 12/19/23 10:43, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>> But, I want }} to do the size-specific compilation,
>>>> eventually. To do that properly, I want to go to a dual-xt system and
>>>> avoid explicit STATE-dependence (which has other benefits we've
>>>> discussed in the past).
>>>
>>> Avoiding STATE is a good idea.  However, what you have in mind seems
>>> to be an optimization, not something like S".  Dual-xt words are good
>>> for stuff like S"; you can use them for optimization, but the
>>> intelligent COMPILE, is better for that.
>>>
>
>> We had a discussion about this earlier, and I did not like the design
>> of SET-OPTIMIZER changing the behavior of COMPILE, . I don't see the
>> drawback of changing the xt for compilation state as a method of
>> optimization. Why add extra complexity with SET-OPTIMIZER when you
>> don't have to?
>
>> --
>> Krishna
>
> LXF has from the beginning used the compiling XT also for optimization
> (code generation). COMPILE, just compiles a call to the XT.
> This works perfectly well and is easy to implement.
> LXF has about 400 words that generate code while compiling.
>

This is my preference -- COMPILE, should simply compile the code needed
to execute the xt given to it and not do something clever by
substituting a different xt for it.

--
Krishna

Krishna Myneni wrote:
> This is my preference -- COMPILE, should simply compile the code needed
> to execute the xt given to it and not do something clever by
> substituting a different xt for it.

Counterexample:
Code inlining is a simple optimisation technique. Why not use it?

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On 12/19/23 10:43, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> But, I want }} to do the size-specific compilation,
>>> eventually. To do that properly, I want to go to a dual-xt system and
>>> avoid explicit STATE-dependence (which has other benefits we've
>>> discussed in the past).
>>
>> Avoiding STATE is a good idea. However, what you have in mind seems
>> to be an optimization, not something like S". Dual-xt words are good
>> for stuff like S"; you can use them for optimization, but the
>> intelligent COMPILE, is better for that.
>>
>
>We had a discussion about this earlier, and I did not like the design of
>SET-OPTIMIZER changing the behavior of COMPILE, .

If it changes the behaviour of COMPILE, (rather than the
implementation of that behaviour), that's a mistake in the use of
SET-OPTIMIZER: Whatever you do, it must not change the behaviour.

>I don't see the
>drawback of changing the xt for compilation state as a method of
>optimization. Why add extra complexity with SET-OPTIMIZER when you don't
>have to?

* It's a separation of concerns: SET-OPTIMIZER is for optimization and
must not change the behaviour (i.e., if you replace the call to
SET-OPTIMIZER with DROP, the program should still work), whereas
SET->COMP (and related words such as INTERPRET/COMPILE:) changes the
compilation semantics, i.e., the behaviour.

* If you implement [COMPILE], you need to know if a word has
non-default compilation semantics. If you have the separation of
concerns above, that is easy: If it does not have the default
NAME>COMPILE method (DEFAULT-NAME>COMP), it has non-default
compilation semantics. If you are using this mechanism for a
purpose that does not change the compilation semantics, you have to
add a mechanism that tells the compiler about the difference, and
the user has to provide this information in some way, too (e.g., by
having INTERPRET/COMPILE: if the resulting word has non-default
compilation semantics and INTERPRET/OPTIMIZE: if it has).

* There is a difference in performance if an xt is COMPILE,ed; with
the intelligent COMPILE, the result is as good as going through the
text interpreter; with INTERPRET/COMPILE:, you get a generic call to
the xt, while the text interpreter produces better code.

* The COMPILE, methods get the xt that is COMPILE,d (they have the
same stack effect as COMPILE,), which helps in using the same
implementation for several xts. E.g., FOLD1-1 is the optimizer of
29 words (all with the stack effect ( x -- x ). INTERPRET/COMPILE:
lacks this flexibility. I guess you could have a way that provides
the xt or nt of the word for which you are performing the
compilation semantics; not sure how well that would work.

Finally, my vision for the (far-away) future is that words such as S"
and TO go away, and with them the need for words such as
INTERPRET/COMPILE: or (worse) STATE-smart words.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>This is my preference -- COMPILE, should simply compile the code needed
>to execute the xt given to it and not do something clever by
>substituting a different xt for it.

So IYO COMPILE, should be defined as

: compile, ( xt -- )
postpone literal postpone execute ;

?

And of course the POSTPONE EXECUTE must do something other than
"COMPILE," the xt or EXECUTE, or this results in an endless recursion.

Interestingly, development Gforth has this as "GENERAL-COMPILE," and
this is the implementation of "COMPILE," if no more specialized
version is installed. E.g., the more specialized implementation of
COMPILE, for a constant is:

: constant, ( xt -- )
>body @ postpone literal ;

This does not substitute a different xt for the given xt, it compiles
the value of the constant as a literal. Why do you think we should
compile with GENERAL-COMPILE, instead?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 12/22/23 03:00, minforth wrote:
> Krishna Myneni wrote:
>> This is my preference -- COMPILE, should simply compile the code
>> needed to execute the xt given to it and not do something clever by
>> substituting a different xt for it.
>
> Counterexample:
> Code inlining is a simple optimisation technique. Why not use it?

I do use code inlining. I don't understand what you mean by this being a
counter-example. For example, you may need to give interpretation
semantics for a word that performs a sequence of words, but the
compilation semantics does inline compiling of the sequence.

Or am I misunderstanding you?

--
Krishna

In article <um5aeu$1p3uf$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>On 12/22/23 03:00, minforth wrote:
>> Krishna Myneni wrote:
>>> This is my preference -- COMPILE, should simply compile the code
>>> needed to execute the xt given to it and not do something clever by
>>> substituting a different xt for it.
>>
>> Counterexample:
>> Code inlining is a simple optimisation technique. Why not use it?
>
>I do use code inlining. I don't understand what you mean by this being a
>counter-example. For example, you may need to give interpretation
>semantics for a word that performs a sequence of words, but the
>compilation semantics does inline compiling of the sequence.
>
>Or am I misunderstanding you?

Look at my :I
EXAMPLE:
:I R> 1+ >R ;
the code is just inlined without engaging the return stack

:I compiles things and in compilation state it copies until (;)
(an alias for exit), otherwise it executes a normal definition.

: :I
CREATE IMMEDIATE ] LATEST HIDDEN !CSP DOES> \ Just like :
STATE @ IF
BEGIN $@ DUP '(;) <> WHILE , REPEAT 2DROP
ELSE
>R \ Just like :
THEN ;

[In this simple ciforth there is no distinction between , and
COMPILE, . ]

Now it is beyond me, that this has anything to do with "optimisation".
Optimisation in the sense, replacing code sequence with faster
execution code sequences.

>--
>Krishna
>

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

Krishna Myneni wrote:
> I do use code inlining. I don't understand what you mean by this being a
> counter-example. For example, you may need to give interpretation
> semantics for a word that performs a sequence of words, but the
> compilation semantics does inline compiling of the sequence.

I am a little surprised that this is a topic of discussion. See also:
https://ethz.ch/content/dam/ethz/special-interest/infk/ast-dam/documents/Theodoridis-ASPLOS22-Inlining-Paper.pdf

Well, I consider compiling a single xt to be equivalent to compiling a
function call. Including the function body (apart from reducing function
call overhead)
a) eliminates the xt, so it is no longer there for decompilation or
introspection, and
b) creates a wider area for further optimisations.
For example, peephole optimisation can now extend across the boundaries
of the host code and inlined code, et cetera.

On 12/22/23 10:59, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> This is my preference -- COMPILE, should simply compile the code needed
>> to execute the xt given to it and not do something clever by
>> substituting a different xt for it.
>
> So IYO COMPILE, should be defined as
>
> : compile, ( xt -- )
> postpone literal postpone execute ;
>
> ?
>
The definition of COMPILE, should be equivalent to that, yes. The actual
implementation may be system dependent. This appears to me to be
consistent with the standard,

6.2.0945
COMPILE,
“compile-comma”
CORE EXT
Interpretation: Interpretation semantics for this word are undefined.
Execution: ( xt – – )
Append the execution semantics of the definition represented by xt to
the execution semantics of the current definition.

And, of course, the execution semantics of xt may be performed by EXECUTE.

> And of course the POSTPONE EXECUTE must do something other than
> "COMPILE," the xt or EXECUTE, or this results in an endless recursion.
>
That is the programmer's concern.

> Interestingly, development Gforth has this as "GENERAL-COMPILE," and
> this is the implementation of "COMPILE," if no more specialized
> version is installed. E.g., the more specialized implementation of
> COMPILE, for a constant is:
>
> : constant, ( xt -- )
> >body @ postpone literal ;
>

Why do you need a specialized version of COMPILE, for a constant? The
following should work for a constant named C :

In interpreter state:

' C EXECUTE

In compilation state:

: compile-C ['] C compile, ; immediate

: test compile-C . ;

--

5 constant C
ok
' C execute
ok
..s

5
ok
: compile-C ['] C compile, ; immediate
ok
: test compile-C . ;
ok
test
5 ok

Of course, the point of our discussion is that you can make optimized
code for C in compilation state.

> This does not substitute a different xt for the given xt, it compiles
> the value of the constant as a literal. Why do you think we should
> compile with GENERAL-COMPILE, instead?
>

In a dual-xt system, you are free to specify whatever compilation
sequence you wish -- isn't that the point?

--
Krishna