hello,

did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

I'm also interested if you have such references as books too :) even I have already many beginners books.

regards.

In article <9652494d-e625-4e86-a6b0-3fd25851e09en@googlegroups.com>,
gobli...@gmail.com <goblinrieur@gmail.com> wrote:
>hello,
>
>did anyone have wrote a specific document about optimization & good
>practice or tips in forth ? or have good links about that to provide ?
>
>I'm still learning & have access to I think all "well known" sites but I
>wonder continue my learning :) & rewrite a better way my current
>trainning codes.
>
>I'm also interested if you have such references as books too :) even I
>have already many beginners books.

https://home.hccnet.nl/a.w.m.van.der.horst/forthlectures.html
This contains a write up how to do optimisers in Forth.
I actually have implemented this for ciforth.
Also Marcel Hendrix took inspiration from it. (His iforth and
MPE-forth are probably the fastest Forth's around.).

>
>regards.
>
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 -

gobli...@gmail.com schrieb am Samstag, 5. August 2023 um 11:11:11 UTC+2:
> hello,
>
> did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?
>
> I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.
>
> I'm also interested if you have such references as books too :) even I have already many beginners books.

I guess you have gone through Leo Brodie's two classic books.

Thereafter it really depends on your optimisation goal. For instance
- execution speed
- least memory footprint
- least burnt milliwatts embedded
- most concise source code
- ease of maintenance in a team

For the first three: know your hardware!

This does not answer your question, but might explain why there are not
many generic reference papers around. Although not for Forth, but for assembler and C,
I found Agner Fog's papers on optimization very helpful:
https://www.agner.org/optimize/

On Saturday, August 5, 2023 at 5:11:11 AM UTC-4, gobli...@gmail.com wrote:
> hello,
>
> did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?
>
> I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.
>
> I'm also interested if you have such references as books too :) even I have already many beginners books.
>
> regards.

Not sure what you mean by optimizing. It could mean an optimizing compiler but it could also
mean how to write more efficient Forth code.

On the latter issue there is a strange aspect of Forth that is more akin to a CPU instruction set.
By that I mean there are hundreds of these little code snippets and they can be used in ways
that are not always obvious. As an example the word COUNT is generally thought of as a way
to unpack a counted string and return the text address and the length but I was amazed to see
it used as a way to index a string, character by character, like this:

: TYPE ( addr len -- ) 0 DO COUNT EMIT LOOP DROP ;

COUNT could probably also be used as part of a character parser.
I have only recently started trying to see Forth this way so that is why I am commenting.

*DISCLAIMER : There are real experts on this subject In this forum.
These comments are hobby coder trying to learn something on the matter.

My hobby work involves a machine with glacial performance so making faster Forth is rewarding.
Also with a really slow machine you get first hand experience on what really makes a difference.

One approach I took to optimizing indirect threaded code was to copy primitive code words
in memory end to end and use them as "headless" definitions. I believe GForth calls these
super-instructions and does them as a matter of course. (? Anton ?)

This gave some benefits but I found other bottle-necks.
If you are going to compile native code then there are more efficient ways to handle
variables and constants so that led to detecting those words and compiling appropriate code.

But then a bottle-neck shows up around branching and looping because the threaded interpreter
is limiting the flat out speed of IF, ELSE, WHILE, AGAIN and UNTIL so that led to detecting
those words and compiling native code jumps.

If it is of interest you can see the evolution in these two files.
They may provide some ideas from someone else who is feeling their way along. :-)

https://github.com/bfox9900/CAMEL99-ITC/blob/master/LIB.ITC/INLINE.FTH

https://github.com/bfox9900/CAMEL99-ITC/blob/master/LIB.ITC/JIT.FTH

To give you a sense of the improvement achievable, 10 iterations of the Byte Magazine Sieve
takes 120 seconds running on this 1978 era CPU using ITC Camel Forth.
(LOL I'm not kidding)

Using the JIT on the computational section reduces the time to 49 seconds.

However a fully native code version in a Machine Forth I wrote, using native registers as locals
runs in just under 10 seconds.

All that to say compilers like VFX and iForth are doing much more than the obvious stuff.

On 6/08/2023 12:07 am, minforth wrote:
> gobli...@gmail.com schrieb am Samstag, 5. August 2023 um 11:11:11 UTC+2:
>> hello,
>>
>> did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?
>>
>> I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.
>>
>> I'm also interested if you have such references as books too :) even I have already many beginners books.
>
> I guess you have gone through Leo Brodie's two classic books.
>
> Thereafter it really depends on your optimisation goal. For instance
> - execution speed
> - least memory footprint
> - least burnt milliwatts embedded
> - most concise source code
> - ease of maintenance in a team
>
> For the first three: know your hardware!
>
> This does not answer your question, but might explain why there are not
> many generic reference papers around. Although not for Forth, but for assembler and C,
> I found Agner Fog's papers on optimization very helpful:
> https://www.agner.org/optimize/

Following that link I found myself at the MASM website browsing the following page:

https://www.masm32.com/why.htm

Reading the third paragraph and substituting each occurrence of "MASM" with "FORTH",
it struck me as something Moore might say. His 'no compromise' stance is legend.
MASM users knowing what they're about simply say 'not for the faint hearted'. No
mention of ease of maintenance in a team as a goal at all. Perhaps it's Forth that
has lost its way.

dxforth schrieb am Samstag, 5. August 2023 um 19:20:48 UTC+2:
> On 6/08/2023 12:07 am, minforth wrote:
> > gobli...@gmail.com schrieb am Samstag, 5. August 2023 um 11:11:11 UTC+2:
> >> hello,
> >>
> >> did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?
> >>
> >> I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.
> >>
> >> I'm also interested if you have such references as books too :) even I have already many beginners books.
> >
> > I guess you have gone through Leo Brodie's two classic books.
> >
> > Thereafter it really depends on your optimisation goal. For instance
> > - execution speed
> > - least memory footprint
> > - least burnt milliwatts embedded
> > - most concise source code
> > - ease of maintenance in a team
> >
> > For the first three: know your hardware!
> >
> > This does not answer your question, but might explain why there are not
> > many generic reference papers around. Although not for Forth, but for assembler and C,
> > I found Agner Fog's papers on optimization very helpful:
> > https://www.agner.org/optimize/
> Following that link I found myself at the MASM website browsing the following page:
>
> https://www.masm32.com/why.htm
>
> Reading the third paragraph and substituting each occurrence of "MASM" with "FORTH",
> it struck me as something Moore might say. His 'no compromise' stance is legend.
> MASM users knowing what they're about simply say 'not for the faint hearted'. No
> mention of ease of maintenance in a team as a goal at all. Perhaps it's Forth that
> has lost its way.

You are right in that "ease of maintenance" is of little importance in one-man software
shows, eg like Forth hobbyist projects, or for assembly trick programming nerds.

For industrial applications "ease of maintenance" has a quite different impact. Imagine
MCUs running for years somewhere on the globe. The paying customer wants some
software troubleshooting or update with minimal downtime. Now put yourself in the shoes
of the service engineer who has to go there...

On 6/08/2023 5:02 am, minforth wrote:
> dxforth schrieb am Samstag, 5. August 2023 um 19:20:48 UTC+2:
>> On 6/08/2023 12:07 am, minforth wrote:
>>> gobli...@gmail.com schrieb am Samstag, 5. August 2023 um 11:11:11 UTC+2:
>>>> hello,
>>>>
>>>> did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?
>>>>
>>>> I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.
>>>>
>>>> I'm also interested if you have such references as books too :) even I have already many beginners books.
>>>
>>> I guess you have gone through Leo Brodie's two classic books.
>>>
>>> Thereafter it really depends on your optimisation goal. For instance
>>> - execution speed
>>> - least memory footprint
>>> - least burnt milliwatts embedded
>>> - most concise source code
>>> - ease of maintenance in a team
>>>
>>> For the first three: know your hardware!
>>>
>>> This does not answer your question, but might explain why there are not
>>> many generic reference papers around. Although not for Forth, but for assembler and C,
>>> I found Agner Fog's papers on optimization very helpful:
>>> https://www.agner.org/optimize/
>> Following that link I found myself at the MASM website browsing the following page:
>>
>> https://www.masm32.com/why.htm
>>
>> Reading the third paragraph and substituting each occurrence of "MASM" with "FORTH",
>> it struck me as something Moore might say. His 'no compromise' stance is legend.
>> MASM users knowing what they're about simply say 'not for the faint hearted'. No
>> mention of ease of maintenance in a team as a goal at all. Perhaps it's Forth that
>> has lost its way.
>
> You are right in that "ease of maintenance" is of little importance in one-man software
> shows, eg like Forth hobbyist projects, or for assembly trick programming nerds.
>
> For industrial applications "ease of maintenance" has a quite different impact. Imagine
> MCUs running for years somewhere on the globe. The paying customer wants some
> software troubleshooting or update with minimal downtime. Now put yourself in the shoes
> of the service engineer who has to go there...

I've been there as an electronics service engineer. There was no question of HP or
Tektronix dumbing down their products for fear it might upset some future service
manager. Either the service organization has personnel of sufficient competence to
handle it - or they don't. Same applies to designers.

On 6/08/2023 2:54 am, Brian Fox wrote:
> On Saturday, August 5, 2023 at 5:11:11 AM UTC-4, gobli...@gmail.com wrote:
>> hello,
>>
>> did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?
>>
>> I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.
>>
>> I'm also interested if you have such references as books too :) even I have already many beginners books.
>>
>> regards.
>
> Not sure what you mean by optimizing. It could mean an optimizing compiler but it could also
> mean how to write more efficient Forth code.
>
> On the latter issue there is a strange aspect of Forth that is more akin to a CPU instruction set.
> By that I mean there are hundreds of these little code snippets and they can be used in ways
> that are not always obvious.

Further to the first point, it would be a mistake to judge 'good Forth' by the standards
of other languages. The latter factor in environmental factors such as optimizing compilers.
Moore's position has been write optimum code and the need for fancy compilers goes away.
There's a reason GCC is such a monster. I wish its team of maintainers the best of luck.

On Saturday, August 5, 2023 at 11:42:07 PM UTC-5, dxforth wrote:
> On 6/08/2023 5:02 am, minforth wrote:

Never was an optimizing Nazi but always pursued
tricks of the trade e.g. xor register to itself
instead of moving zero into it. But after Hans
remark about bad style using flag as a mask and
previous comments of Albert about 'premature
optimization' it finally sunk in. Old habits
are too ingrained to completely give but now
strive to write straight code rather than some
peep-hole optimization. Just assume if someone
wants it optimized, they can run it through some
one's optimizing compiler. Or if in a speed bind
somewhere then sure attack it.
Currently in my latest retro Forth I'm spending
time importing code level word form previous
works and converting to them high level words in
the new Forth. In the past I would have had a
hard time making myself do such a thing but now
have no concern at all. Even found a new factor
I haven't seen before (probably with good reason)
"U->D", unsigned single to signed double.
--
me

On 5 Aug 2023 at 11:11:09 CEST, "goblinrieur@gmail.com"
<goblinrieur@gmail.com> wrote:

> did anyone have wrote a specific document about optimization & good practice
> or tips in forth ? or have good links about that to provide ?

Optimisation of Forth is really no different than for other languages. If
there is a difference, it is
that the Forth basic block (what's inside a control structure) is usually
very/rather small.

Start with all the classic texts from the dragon books onwards. See also
Fraser and Hansen - Retargetable C compiler: Design and implementation
get the second edition

Fischer & LeBlanc (et al) - Crafting a Compiler
We liked it. There appears to be PDF floating around.

Note that paper books about compiler are expensive.

You will also fing that the parsing requirements for Forth are almost trivial,
and that the key
is in designing the data structures to represent the Forth data and the
instruction selection.
For example, DUP need generate no code until one part is copied modified or
moved. For
example
DUP 8 + @
can be reduced to one instruction in many instruction sets. This example
requires you
to perform some degree of back-tracking in some designs.

You have to decide what your objectives are.

Stephen

>
> I'm still learning & have access to I think all "well known" sites but I
> wonder continue my learning :) & rewrite a better way my current trainning
> codes.
>
> I'm also interested if you have such references as books too :) even I have
> already many beginners books.
>
> regards.
>

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On 7/08/2023 2:26 am, S Jack wrote:
> On Saturday, August 5, 2023 at 11:42:07 PM UTC-5, dxforth wrote:
>> On 6/08/2023 5:02 am, minforth wrote:
>
> Never was an optimizing Nazi but always pursued
> tricks of the trade e.g. xor register to itself
> instead of moving zero into it. But after Hans
> remark about bad style using flag as a mask and
> previous comments of Albert about 'premature
> optimization' it finally sunk in. Old habits
> are too ingrained to completely give but now
> strive to write straight code rather than some
> peep-hole optimization. Just assume if someone
> wants it optimized, they can run it through some
> one's optimizing compiler. Or if in a speed bind
> somewhere then sure attack it.

In any code one writes there will be opportunities to optimize.
I don't feel inclined to leave to an optimizer what I can do
myself. The latter are certainly not entitled to call Forth
code "tricky" if that's what they do under the hood out of sight.

On Monday, August 7, 2023 at 5:23:06 AM UTC-5, dxforth wrote:

> In any code one writes there will be opportunities to optimize.

Optimized for which processor? A general optimization
perhaps, but wouldn't that be "premature".

Some months back someone published a nice math library.
All the code was straight Forth code, most words
short and sweet. There were no "AND TRUE"s to avoid
IF statements or other such common Forth idiosyncrasy.
I thought it good clear logic; no need to muddle with
optimization until optimization is needed.
In Frog I reluctantly changed TRUE from 1 to -1 for
that advantage of avoiding IF statements. I was
reluctant because the assemblers that I knew had
instructions that expected 1 for TRUE and I wanted
to keep my Forth close to assembly. I always regretted
it, not for any practical reason but for preference,
and planned on changing it back. Then came Toad, pure
retro, and I'm happy to have TRUE is 1 back along with
the other warts.
In industry software is always having to make up for
short comings of the hardware. Well, now being free
I no longer feel the need to follow the hardware.
I pretend perfect hardware exists that can handle
IF statements without penalty.
--
me

On 8/08/2023 1:43 am, S Jack wrote:
> On Monday, August 7, 2023 at 5:23:06 AM UTC-5, dxforth wrote:
>
>> In any code one writes there will be opportunities to optimize.
>
> Optimized for which processor? A general optimization
> perhaps, but wouldn't that be "premature".

I'm talking about forth. Forth is low level compared to most HLL with
the result concise forth translates to efficient code irrespective of
processor. If one includes HLL elements such as locals the correlation
between source and code generated is muddied. All the programmer can
do in the latter case is apply post-optimization and hope for the best.
But since forth is still low level it limits what such optimizers can
achieve without re-organizing the code. Folks may wish to test their
optimizers here:

https://pastebin.com/HpDnzsGj

> Some months back someone published a nice math library.
> All the code was straight Forth code, most words
> short and sweet. There were no "AND TRUE"s to avoid
> IF statements or other such common Forth idiosyncrasy.
> I thought it good clear logic; no need to muddle with
> optimization until optimization is needed.

Sometimes there's nothing to optimize. I think it's a mistake to apply
norms of other languages to Forth and called it idiosyncratic. I did
that when I first came to Forth. In my case the carry-over was BASIC.