On 6 Jan 2022 at 10:52:35 CET, "dxforth" <dxforth@gmail.com> wrote:

> On 6/01/2022 20:09, Stephen Pelc wrote:
>> On 6 Jan 2022 at 02:57:08 CET, "dxforth" <dxforth@gmail.com> wrote:
>>>
> I was politely told I could go and create my own standard. It turned
> out to be the best advice I received and I've been happy to pass it on.

I always find when doing a new development that there are parts not
covered by the standard - of course there are. The discussion about transient
dictionary regions is a case in point. A client asked some years ago, we
delivered and it's in the VFX file Examples/transients.fth.

A standard only becomes relevant when several want the same thing
badly enough. The discussion about { or {: is irrelevant compared to
realising that most people dislike LOCALS| ... |

There are parts of the standard that were politically expedient to get a
result. Just part of daily life, and not worth screaming about.

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

On 2022-01-06 08:01, Nickolay Kolchin wrote:
> On Thursday, January 6, 2022 at 1:26:21 AM UTC+3, Ruvim wrote:

>>
>> There is no need to worry about any "closed club" and its games at all.
>> Just do it.
>>
>
> Nah. I have all rights, to poke Forth200X members in their own shit. And
> it's easy, cause in 18 years they produced nothing but shit.

Of course, since it helps you a lot in your possible work on a standard
library.

And then other third party people, for which you owe nothing, will
evaluate your work as a shit (according to their own expectations) and
will poke you in your shit. It also will help them a lot to increase
their low self-esteem (actually will not).

But it's a wrong way.

A community, communications and discussion are essential for such a work
as standardization and standard libraries. And you need other people to
utilize an effect of synergy, after all.

Devaluation of other people's work just reduces your own opportunities,
and nothing more.

>> Don't sure a language needs a care at all. Who actually need a care are
>> people. But you have to ask/investigate what people need.
>>
>> You seem to think that they need a standard library.
>> Why don't you create such a library?
>>
>> Well, you probably want to make this library portable. What are you
>> missing for that?
>
> I miss LATEST, CREATED, namespaces, common approach to multithreading,
> recognizers, common approach for embedded, better control
> structures, better locals, separate compilation, etc...

It's inefficient to cover everything at once.

A standard library can be considered as a set of libraries that don't
need to know internal details of each other, and each of them is focused
to some limited topic.

Some such libraries are even totally independent from other libraries
(i.e. the standard basis is enough to implement them). Why don't to
start from them? Maybe such your libraries are already published anywhere?

Then you could implement some small system-dependent API for a couple of
systems and develop a library that requires such API (e.g. "CREATED" or
"LATEST", or multi-threading).

Nothing special instructions or approvals from Forth200x are needed for
that. Just do it. It could be a sound basis for further work.

> I.e. all obvious stuff that Forth200x was expected to clarify.

A more efficient way is to stop expecting and waiting that somebody will
design specifications for you. Suggest a specification by yourself, ask
for feedback, discuss and tune it. Nothing can stop you but your own
abilities.

--
Ruvim

Am 05/01/2022 um 11:16 schrieb Paul Rubin:
> dxforth <dxforth@gmail.com> writes:
>> as Moore put it: "The knowledge and effort required to mine library
>> resources is comparable to that required to understand and code the
>> problem directly."
>
> Even in Moore's era there were tons of libraries for stuff that most of
> us wouldn't know how to code even today. To name just one example, one
> of my math teachers (a numerics guy) used to say that any idiot could
> write a matrix inversion routine, but to find the eigenvalues you had to
> know what you were doing. So there were all kinds of linear algebra
> packages.
>
> I guess on the minicomputers where Forth originated, there wasn't enough
> code space for any libraries to be really complicated, so a clever
> enough Forther could write everything. Today there is so much code in
> any application that even if you know how to write all the libraries
> from scratch, the effort required would be ridiculous. Jpeg renderer
> anyone? Video codecs? FFmpeg is a huge piece of code.
>
> Even in the small embedded realm, there is more to simple applications
> than meets the eye. Here is something (CO2 monitor with display) that I
> want to build:
>
> https://www.adafruit.com/product/4867
>
> See, there is a CO2 sensor with an I2C interface connected to a small
> MCU, and the MCU also runs a display. Yes it could all be programmed in
> Forth. But look at all that code: bit bang or hardware I2C
> communication, and turning the display pixels on and off to show
> messages, thus needing fonts and all that stuff (sorry, you can't just
> EMIT a character to a dot matrix display). Easier to just use the
> libraries.
>
> Actually I might use a Linux board (Raspberry Pi Zero W) just to make
> all that easier. Run a web server on the RPi, and use a mobile phone
> browser as the display. The amount of code involved (Linux, web server,
> phone OS, web browser) is probably more than all the Forth code that has
> ever been written, but it's a fairly simple task of plugging stuff
> together, with Python script as glue.
>
> See also:
>
> http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail
Hi Paul,

I won't get drawn into the library discussion today, but I just wanted
to say thanks for the link :
http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail
- great observation!!!

Cheers,
Howerd

On 2021-12-29 18:52, Anton Ertl wrote:
> Nickolay Kolchin <nbkolchin@gmail.com> writes:
>> On Thursday, December 23, 2021 at 9:53:01 PM UTC+3, Anton Ertl wrote:

>>>> - Python: This is new standard. We have a script that will help you port code
>>>> from old one. It doesn't work most of the time, but at least we tried.
>>>
>>> Almost killed Python, and many people have written about switching to
>>> other languages thanks to the breaking changes in Python 3, and the
>>> Python maintainers have vowed never to do such a thing again.
>>>
>>
>> Really? https://www.tiobe.com/tiobe-index/python/
>>
>> Guido just have balls to do unpopular move.
>
> He lacked the foresight to take on the seemingly harder work of taking
> a backwards-compatible path to where he wanted to go. My impression
> is that with hindsight, he would not do it that way again.

I have just accidentally stumbled upon an interview [1] that confirms
this point:

"I normally talk about that as a mistake, because Python was more
successful than the core developers realised and so we should have been
much more aware and supportive of transitioning from Python 2 to Python
3," said van Rossum.

[1] Programming languages: Why Python 4.0 might never arrive, according
to its creator (2021-05)
https://www.techrepublic.com/article/programming-languages-why-python-4-0-will-probably-never-arrive-according-to-its-creator/

>
> Also, if Python had advertised from the start that Python projects
> would find themselves in a maze of interdependencies with many only
> supporting Python 2, and a deadline when everything should be
> converted to Python 3, how many people would have chosen Python for
> their project? This is where Python's library strength turned into a
> liability.

--
Ruvim

On 7/01/2022 01:31, Stephen Pelc wrote:
> On 6 Jan 2022 at 10:52:35 CET, "dxforth" <dxforth@gmail.com> wrote:
>
>> On 6/01/2022 20:09, Stephen Pelc wrote:
>>> On 6 Jan 2022 at 02:57:08 CET, "dxforth" <dxforth@gmail.com> wrote:
>>>>
>> I was politely told I could go and create my own standard. It turned
>> out to be the best advice I received and I've been happy to pass it on.
>
> I always find when doing a new development that there are parts not
> covered by the standard - of course there are. The discussion about transient
> dictionary regions is a case in point. A client asked some years ago, we
> delivered and it's in the VFX file Examples/transients.fth.
>
> A standard only becomes relevant when several want the same thing
> badly enough. The discussion about { or {: is irrelevant compared to
> realising that most people dislike LOCALS| ... |
>
> There are parts of the standard that were politically expedient to get a
> result. Just part of daily life, and not worth screaming about.

Indeed. Anton was most pissed-off about LOCALS| when it was announced
and even called for a boycott. Floats on the data stack was another
of his pet peeves he called "insane". The best way to effect change
however is to install oneself as leader - which is exactly what occurred
in 2004. When it eventually came time for me to leave, it was without
regret - albeit some embarrassment it had taken so long. I guess some
things can't be rushed.

On 7/01/2022 04:35, Ruvim wrote:
> On 2022-01-06 08:01, Nickolay Kolchin wrote:
>> On Thursday, January 6, 2022 at 1:26:21 AM UTC+3, Ruvim wrote:
>
>
>>>
>>> There is no need to worry about any "closed club" and its games at all.
>>> Just do it.
>>>
>>
>> Nah. I have all rights, to poke Forth200X members in their own shit. And
>> it's easy, cause in 18 years they produced nothing but shit.
>
> Of course, since it helps you a lot in your possible work on a standard
> library.
>
> And then other third party people, for which you owe nothing, will
> evaluate your work as a shit (according to their own expectations) and
> will poke you in your shit. It also will help them a lot to increase
> their low self-esteem (actually will not).
>
> But it's a wrong way.
>
> A community, communications and discussion are essential for such a work
> as standardization and standard libraries. And you need other people to
> utilize an effect of synergy, after all.

Nobody need tyrants - unless they cannot fend for themselves.

On 2022-01-07 02:02, dxforth wrote:
> On 7/01/2022 04:35, Ruvim wrote:
>> On 2022-01-06 08:01, Nickolay Kolchin wrote:
>>> On Thursday, January 6, 2022 at 1:26:21 AM UTC+3, Ruvim wrote:
>>>>
>>>> There is no need to worry about any "closed club" and its games at all.
>>>> Just do it.
>>>
>>> Nah. I have all rights, to poke Forth200X members in their own shit. And
>>> it's easy, cause in 18 years they produced nothing but shit.
>>
>> Of course, since it helps you a lot in your possible work on a standard
>> library.
>>
>> And then other third party people, for which you owe nothing, will
>> evaluate your work as a shit (according to their own expectations) and
>> will poke you in your shit. It also will help them a lot to increase
>> their low self-esteem (actually will not).
>>
>> But it's a wrong way.
>>
>> A community, communications and discussion are essential for such a work
>> as standardization and standard libraries. And you need other people to
>> utilize an effect of synergy, after all.
>
> Nobody need tyrants - unless they cannot fend for themselves.

Agreed. And what?

Tyrants impose they will by violence (or threatening of).

On 7/01/2022 11:01, Ruvim wrote:
> On 2022-01-07 02:02, dxforth wrote:
>> On 7/01/2022 04:35, Ruvim wrote:
>>> On 2022-01-06 08:01, Nickolay Kolchin wrote:
>>>> On Thursday, January 6, 2022 at 1:26:21 AM UTC+3, Ruvim wrote:
>>>>>
>>>>> There is no need to worry about any "closed club" and its games at all.
>>>>> Just do it.
>>>>
>>>> Nah. I have all rights, to poke Forth200X members in their own shit. And
>>>> it's easy, cause in 18 years they produced nothing but shit.
>>>
>>> Of course, since it helps you a lot in your possible work on a standard
>>> library.
>>>
>>> And then other third party people, for which you owe nothing, will
>>> evaluate your work as a shit (according to their own expectations) and
>>> will poke you in your shit. It also will help them a lot to increase
>>> their low self-esteem (actually will not).
>>>
>>> But it's a wrong way.
>>>
>>> A community, communications and discussion are essential for such a work
>>> as standardization and standard libraries. And you need other people to
>>> utilize an effect of synergy, after all.
>>
>> Nobody need tyrants - unless they cannot fend for themselves.
>
> Agreed. And what?
>
> Tyrants impose they will by violence (or threatening of).

Or by dangling a carrot. The carrot is not in the donkey's reach but
close enough to keep it moving in the desired direction. I imagine
Python etc is popular because the carrot was provided up front. One
is still a donkey - but a contented one.

> "I normally talk about that as a mistake, because Python was more
> successful than the core developers realised and so we should have been
> much more aware and supportive of transitioning from Python 2 to Python
> 3," said van Rossum.

Yes, 2->3 is probably the best example of the _weakness_ of Guido's greatest
strength in forming and holding a consensus. I suspect the string codec
purists, along with all the frustrated pedants and language lawyers, were
shouting so loudly that Guido mistook that as the consensus of the community.

I would have forgiven even larger breaking changes, if he had addressed
true parallel threading. But to break and fragment Python in exchange for
such petty Purity of Essence type stuff? It was frustrating.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On 8/01/2022 01:49, Andy Valencia wrote:
>> "I normally talk about that as a mistake, because Python was more
>> successful than the core developers realised and so we should have been
>> much more aware and supportive of transitioning from Python 2 to Python
>> 3," said van Rossum.
>
> Yes, 2->3 is probably the best example of the _weakness_ of Guido's greatest
> strength in forming and holding a consensus. I suspect the string codec
> purists, along with all the frustrated pedants and language lawyers, were
> shouting so loudly that Guido mistook that as the consensus of the community.
>
> I would have forgiven even larger breaking changes, if he had addressed
> true parallel threading. But to break and fragment Python in exchange for
> such petty Purity of Essence type stuff? It was frustrating.

Trouble in Paradise? Perhaps Forth's lack of public success isn't such a
bad thing if the result is doing what you want. It will mean you will be
judged on what you do rather than the language. Currently the TC and users
can blame each other for being lazy, argumentative, out-of-touch, and not
contributing anything of substance.

dxforth <dxforth@gmail.com> writes:
>Perhaps Forth's lack of public success isn't such a
>bad thing if the result is doing what you want.

You can also do what you want when implementing Python if the goal is
lack of public success.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Friday, January 7, 2022 at 2:54:16 PM UTC, Andy Valencia wrote:
> > "I normally talk about that as a mistake, because Python was more
> > successful than the core developers realised and so we should have been
> > much more aware and supportive of transitioning from Python 2 to Python
> > 3," said van Rossum.
> Yes, 2->3 is probably the best example of the _weakness_ of Guido's greatest
> strength in forming and holding a consensus.

And that strength, not just of Guido but of the Python community(*), is/was
massively important. (Not trying to say you would disagree with this)

The development of, and community around, Python, when I first started using
it in around 1999, was a beautiful thing. It is hilarious to compare it to [what I see
of] the Forth community, even being aware that this is an apples-oranges comparison.

Jon N

On 8/01/2022 21:19, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>Perhaps Forth's lack of public success isn't such a
>>bad thing if the result is doing what you want.
>
> You can also do what you want when implementing Python if the goal is
> lack of public success.

That's just an idea - not reality? Having a Python-like system in Forth
has also been just an idea and not reality.

dxforth <dxforth@gmail.com> writes:
>On 8/01/2022 21:19, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>Perhaps Forth's lack of public success isn't such a
>>>bad thing if the result is doing what you want.
>>
>> You can also do what you want when implementing Python if the goal is
>> lack of public success.
>
>That's just an idea - not reality?

I would not be surprised if it was a reality; many projects achieve
this goal without trying (and without having it as goal). Of course,
if the goal is reached, it is also hard to find such an implementation
through a search engine (who tend to present popular web pages), so I
don't know whether any of the Python implementations I found is really
publicly unsuccessful; however, I see that Jython does not support
Python 3 (available in CPython since 2008), so it seems to have lost
contact with the Python mainstream (or maybe there is still a lot of
mainstream in Python 2?).

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Andy Valencia <vandys@vsta.org> writes:
> I would have forgiven even larger breaking changes, if he had addressed
> true parallel threading. But to break and fragment Python in exchange for
> such petty Purity of Essence type stuff? It was frustrating.

The string codec stuff was a reasonable motivation, but stuff like
getting rid of the print statement?

Anyway it's pretty clear by now that Python 3 was a debacle, and that
while it broke a fair amount of working stuff from Python 2, and fixed a
few minor broken things, it left a lot of other broken things unfixed.
And also, because of the aftereffects of that debacle, that remaining
broken stuff will never be fixed.

The best future path for Python now is probably for its users to migrate
to a dialect hosted on the Erlang BEAM, the way (some) Ruby users
migrated to Elixir.

The right way for Python 3 to have developed would have been delay it
for another year or two until PyPy was working more solidly for Python
2. Then declare CPython to be Python 2, maintained for as long as
Python 2 is maintained, but Python 3 should have been PyPy-based from
the get-go. That would have allowed fixing lots of other stuff besides
the CPython GIL.

dxforth <dxforth@gmail.com> writes:
>> You can also do what you want when implementing Python
> That's just an idea - not reality?

It is reality, there are several alternative implementations of Python.
One of them, MicroPython (micropython.org) and its fork CircuitPython,
has gotten a fair amount if traction in the MCU world. Pay attention
there since that is one fo the remaining holdouts of Forth.

CircuitPython is not as efficient as Forth but that is ok. It runs
nicely on e.g. the Adafruit M0 Trinket which is a 48 mhz ARM Cortex M0
MCU with 256k of program flash and 32k of ram. Forth needs a lot less
resources than that, but who really cares?

The current cheap hobbyist MCU board is the Raspberry Pi Pico which has
two M0 cores at 120 mhz, 256k of ram, and 2MB of SPI flash (there is no
on-chip flash, but there is a ram cache for code from the SPI). The
board costs 4 USD and the MCU chip by itself is 1 USD in single
quantity. The importance of a resident interpreter that fits in 8k is
greatly diminished compated to the 8 bit era.

There are some Forths running on the Pico now, but Micro Python on it is
very nice, and I think the Forth environments are currently less
friendly.

On 9/01/2022 14:29, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>>> You can also do what you want when implementing Python
>> That's just an idea - not reality?
>
> It is reality, there are several alternative implementations of Python.
> One of them, MicroPython (micropython.org) and its fork CircuitPython,
> has gotten a fair amount if traction in the MCU world. Pay attention
> there since that is one fo the remaining holdouts of Forth.

I don't doubt there are forks but do they fit Anton's proposition
of a Python without little or no community support? Forth has
survived in spite of its complaining community.

dxforth <dxforth@gmail.com> writes:
> I don't doubt there are forks but do they fit Anton's proposition
> of a Python without little or no community support?

Micropython and Circuitpython have considerable community support.
There are also some Python implementations without much support and also
without many users. I'm not what what it was that you were asking.

On Sunday, January 9, 2022 at 8:30:22 AM UTC+1, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> > I don't doubt there are forks but do they fit Anton's proposition
> > of a Python without little or no community support?
> Micropython and Circuitpython have considerable community support.
> There are also some Python implementations without much support and also
> without many users. I'm not what what it was that you were asking.

I looked up Circuit Python. I would certainly have gone that route,
had it been available in the 'home computer era' of about 40 years
ago. The introductory YouTube video immediately shows the very
polished hardware apps one can control with it and doesn't talk
about programming at all. I wonder what Circuit Python users
(can) do when they become bored with the pre-cooked stuff.

In the '80s that kind of kits were available also for Forth (e.g.
BBC micro, educational offerings for robotics) but because of
the lacking internet it didn't spread out, or I saw it much too
late in the magazines I could read for free in university libraries.
The hardware they offered was too expensive for me (or so I
thought, prices were never mentioned, no local distributors, no
ideas how to import). I remember I would have bought any
computer at that time, given that it had a Z80 or 68K (hardware
snob that didn't like the 6502 and was not interested at all in
gaming), low enough price, and an assembler or at least a
peek and poke BASIC.
My motivation was a fascination with electronic music, highquality
sound and video, and a desire to have access to very high speed
scientific computing. Only the latter might motivate me were I to
be young again.

-marcel

On 09/01/2022 12:24, Marcel Hendrix wrote:
> On Sunday, January 9, 2022 at 8:30:22 AM UTC+1, Paul Rubin wrote:
>> dxforth <dxf...@gmail.com> writes:
>>> I don't doubt there are forks but do they fit Anton's proposition
>>> of a Python without little or no community support?
>> Micropython and Circuitpython have considerable community support.
>> There are also some Python implementations without much support and also
>> without many users. I'm not what what it was that you were asking.
>
> I looked up Circuit Python. I would certainly have gone that route,
> had it been available in the 'home computer era' of about 40 years
> ago. The introductory YouTube video immediately shows the very
> polished hardware apps one can control with it and doesn't talk
> about programming at all. I wonder what Circuit Python users
> (can) do when they become bored with the pre-cooked stuff.
>
> In the '80s that kind of kits were available also for Forth (e.g.
> BBC micro, educational offerings for robotics) but because of
> the lacking internet it didn't spread out, or I saw it much too
> late in the magazines I could read for free in university libraries.
> The hardware they offered was too expensive for me (or so I
> thought, prices were never mentioned, no local distributors, no
> ideas how to import). I remember I would have bought any
> computer at that time, given that it had a Z80 or 68K (hardware
> snob that didn't like the 6502 and was not interested at all in
> gaming), low enough price, and an assembler or at least a
> peek and poke BASIC.
> My motivation was a fascination with electronic music, highquality
> sound and video, and a desire to have access to very high speed
> scientific computing. Only the latter might motivate me were I to
> be young again.
>
> -marcel

If you discover how to become young again, please do share the info..

On 9/01/2022 21:24, Marcel Hendrix wrote:
>
> I wonder what Circuit Python users
> (can) do when they become bored with the pre-cooked stuff.

Your flirtation with CircuitPython didn't last long :)

Nickolay Kolchin <nbkolchin@gmail.com> writes:
>On Wednesday, January 5, 2022 at 9:51:56 PM UTC+3, Anton Ertl wrote:
>> : foo 1 2 3 4 5 4 pick rot nip nip + + + + ; ok=20
>> see foo=20
>> FOO=20
>> ( 004E3E60 4883C30A ) ADD RBX, # 0A=20
>> ( 004E3E64 C3 ) RET/NEXT
>
>We talk about different things again.
>
>I talk about static stack depth analyze, in Factor spirit:

I wrote about "inlining plus modeling the data stack at compile time
for straight-line code, including constant folding", nothing else.

One interesting thing about this example is that Gforth models
constants on the data stack, so in theory it would be possible that
Gforth also collapses this to just "#10 +". However, in practice pick
just checks the TOS and replaces the PICK with DUP, OVER, THIRD, or
FOURTH if applicable. And DUP and OVER (but not yet THIRD or FOURTH)
also perform their work at compile time if the constant stack is deep
enough. I considered whether to add an optimization for <n> PICK if
the constant stack is deep enough, but I doubt that it is practically
useful, so I did not do it.

Next, I did the PICK optimization manually:

: foo 1 2 3 4 5 1 rot nip nip + + + + ;

And indeed, SEE FOO outputs:

: foo
#10 + ;

>(sometime VFX and LXF generate so identical code, which makes me think=20
>that they are using same compiling engine)

Both model the data stack at compile time, so for source code that
only uses the data stack (and without inlining possibility), getting
the same code is not surprising.

>Your example is just "constant folding". Let's add some conditionals to
>check this:
>
>: foox 1 2 3 4 5 4 pick if + else - then nip nip + ; ok
....
>As we see, adding simple conditional completely destroys their naive
>"constant folding" algorithms.

IF, ELSE and THEN bound straight-line code, so VFX reifies its stack
model at these points.

As for constant folding, let's try something that needs more than
constant folding:

variable a
: foo1 123 a @ + @ + ;
: foo2 a @ 123 + @ + ;
: foo3 a @ swap 123 rot + @ + ;
see foo1 see foo2 see foo3

VFX produces the same code for all three FOOs.

>And when I talk about "pattern matching", I mean that VFX combines "DUP
>*" sequence in one instruction.

: foo dup * ; ok
see foo
FOO
( 004E3F60 488BD3 ) MOV RDX, RBX
( 004E3F63 480FAFDA ) IMUL RBX, RDX
( 004E3F67 C3 ) RET/NEXT

I count two. And whether it's one or two, this does not prove pattern
matching. Modeling the stack is enough to explain it.

>P.S. It is interesting that adding "NOOP" completely disables all
>optimizations in both VFX and LXF.

Reality check:

: foo4 a @ swap 123 rot + @ + noop ;
see foo4

shows (on VFX Forth 64 5.11 RC2):

FOO4
( 004E3FA0 488B15E9D9FBFF ) MOV RDX, FFFBD9E9 [RIP] @004A1990
( 004E3FA7 48035A7B ) ADD RBX, [RDX+7B]
( 004E3FAB E81829F3FF ) CALL 004168C8 NOOP
( 004E3FB0 C3 ) RET/NEXT
( 17 bytes, 4 instructions )

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Stephen Pelc <stephen@vfxforth.com> wrote:
> On 17 Dec 2021 at 19:03:56 CET, "Nickolay Kolchin" <nbkolchin@gmail.com>
> wrote:
>
> > On Friday, December 17, 2021 at 7:21:12 PM UTC+3, Stephen Pelc wrote:
> >> On 16 Dec 2021 at 14:34:48 CET, "Nickolay Kolchin" <nbko...@gmail.com>
> >> wrote:
> >>> 5. The claim that Pelc periodically made about "as complicated as C
> >>> compilers" is complete bullshit. No Forths are even near modern (this
> >>> century) C compilers.
> >> I have never (I hope) claimed thaat the VFX code generator is as complicated
> >> as C compilers, especially since the only models we had were LCC and GCC.
> >> However, I have claimed that VFX uses many algorithms from the usual compiler
> >> set. Note that VFX development started in the late 1990s, and the comparisons
> >> of VFX against C compilers date from then, probably gcc 2.9.5 as far as I
> >> remember.
> >
> > This is from your book dated 2005, last updated 2011 (or 2018?)
> >
> > "Modern Forth implementations usually generate optimised native code, and the
> > good
> > ones produce code of the same quality as the good C compilers." (page 16)
>
> The book is now 16+ years old, and the numbers were ok then.
>
> > Well, according to this https://openbenchmarking.org/test/pts/build-llvm you
> > are only 1.5 times slower than optimising C++ compiler... (LLVM is about 10M
> > lines).
>
> I'll be interested in seeing figures for compiling over 1 million lines of
> code from scratch using off the shelf C compilers.

There are C compilers that can compile of order 1 million lines per
second on single core of modern machine. They generate significantly
worse code than gcc or clang, but self-compiled version is not
much slower than version compiled using gcc (modern machines
seem to be quite good at running "slow" or bloated code).
Concerning "off the shelf", one of fast-compiling C compilers is
Tiny C, which is rather non-standard but have its user comunity.
Other is freely available, but I not sure if anybody makes
serious use of it.

Of course, such compilers do not help compiling Forth code,
OTOH they show that _much_ faster compilation is possible
if you really care about compilation speed. Making fast
Forth compiler probably is harder, due to metaprogramming
on parsing/lexing stage and due to stack on code generation
side. But one should be able to do much better than
30s for 1.2 M loc. Of course, extreme speed up for existing
compiler may take more effort than writing new one.

The LLVM build time above is example of taking advantage of
independent compilation and using a lot (128) of cores.
IIUC for Forth independent compilation would require
language extension.

--
Waldek Hebisch

On Saturday, March 12, 2022 at 2:25:21 PM UTC+1, anti...@math.uni.wroc.pl wrote:
[..]
> The LLVM build time above is example of taking advantage of
> independent compilation and using a lot (128) of cores.
> IIUC for Forth independent compilation would require
> language extension.

The most difficult thing here is finding a Forth program with 1.2MLoc.
The SPICE compiler that I've been working on since 2018 is about
10kLoc (including comments).

-marcel

Marcel Hendrix <mhx@iae.nl> wrote:
> On Saturday, March 12, 2022 at 2:25:21 PM UTC+1, anti...@math.uni.wroc.pl wrote:
> [..]
> > The LLVM build time above is example of taking advantage of
> > independent compilation and using a lot (128) of cores.
> > IIUC for Forth independent compilation would require
> > language extension.
>
> The most difficult thing here is finding a Forth program with 1.2MLoc.
> The SPICE compiler that I've been working on since 2018 is about
> 10kLoc (including comments).

Apparently there are such programs in the wild. If you need one
to test compiler, then it is easy to make fake program of whatever
size you want.

--
Waldek Hebisch