In article <nnd$34fd6cd6$25a88dac@ac6bb1addf3a4136>,
Hans Bezemer <[email protected]> wrote:

On 24-06-2025 13:50, minforth wrote:

On Tue, 24 Jun 2025 9:30:35 +0000, Hans Bezemer wrote:

'Look, Ma - I've solved Forth's biggest problem.' ;-)

No really, I'm not kidding. When done properly Forth actually changes
the way you work. Fundamentally. I explained the sensation at the end of >>> "Why Choose Forth". I've been able to tackle things I would never have
been to tackle with a C mindset. ( https://youtu.be/MXKZPGzlx14 )

Like I always wanted to do a real programming language - no matter how
primitive. Now I've done at least a dozen - and that particular trick
seems to get easier by the day.

And IMHO a lot can be traced back to the very simple principles Forth is >>> based upon - like a stack. Or the triad "Execute-Number-Error". Or the
dictionary. But also the lessons from ThinkForth.

You'll also find it in my C work. There are a lot more "small functions" >>> than in your average C program. It works for me like an "inner API". Not >>> to mention uBasic/4tH - There are plenty of "one-liners" in my
uBasic/4tH programs.

But that train of thought needs to be maintained - and it can only be
maintained by submitting to the very philosophy Forth was built upon. I
feel like if I would give in to locals, I'd be back to being an average
C programmer.

I still do C from time to time - but it's not my prime language. For
this reason - and because I'm often just plain faster when using Forth.
It just results in a better program.

The only thing I can say is, "it works for me". And when I sometimes
view the works of others - especially when resorting to a C style - I
feel like it could work for you as well.

Nine times out of ten one doesn't need the amount of locals which are
applied. One doesn't need a 16 line word - at least not when you
actually want to maintain the darn thing. One could tackle the problem
much more elegant.

It's that feeling..

Why make everything so complicated? An electrician's toolbox looks
different from a horse smith's toolbox. You sound like a horse smith
who frowns at the electrician's toolbox and the electrician's
“philosophy”.

Yes, that's why we have languages like Forth and C - each with its own >philosophy.

The point is, I think there is not enough respect for the Forth
philosophy. It's even publicly denied there is such a philosophy at all.
Or that there are actual, measurable benefits to that philosophy.

And that's the core of the issue, I think.

I'm also puzzled why there is always so emphasis on the "speed" issue. I
mean - if you want speed, do your program in C -O3 so to say. It'll blow
any Forth out of the water. Now I know that there are people concerned
with optimizing Python, but I frown on that as well.

Me too. Many posts post a speed for a program or snippet that they
don't care to explain what it is good for.

If you want to optimize (misnomer for "speed up") the word ALLOCATE
just do
'ALLOCATE OPTIMISED
(This is ciforth: write on essay about this is far superior to the phrase "OPTIMISE ALLOCATE" )

I have been writing an optimiser for some time now.
It is on the backburner, partly because intel 86 is insane, mainly
because it is not really needed. It is more of an academic exercise.
(The byte sieve was optimised to vfxforth level, but honestly not
much else.)
Now riscv is the future. I have succeeded in my experimental optimiser
to get rid of return stack storage (like for loops), and nesting overhead.
I should use the same technique for the data stack, instead of transforming sequences of Intel instructions to smaller once and trying to get rid
of the endless pops and pushes that way.

Now I going to optimise riscv, with much more uniform registers to play
with. And ditch github (USA) in favour of gitee (Chinese).
USA is circling the drain.

I don't mean to say you should close every window to optimization, but
at least admit to one another - it's a secondary problem with Forth.

But to each his own - make love not war. :o)

I'm all for a civil discussion, fully agreed! ;-)

Hans Bezemer

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] writes:

with. And ditch github (USA) in favour of gitee (Chinese).
USA is circling the drain.

Try codeberg.org (Germany) maybe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Paul Rubin <[email protected]d> wrote:

[email protected] writes:

with. And ditch github (USA) in favour of gitee (Chinese).
USA is circling the drain.

Try codeberg.org (Germany) maybe.

USA is no more likely to survive in the near future (taking on
China), than Germany that believes that they should defend Ukrain.
They can't, and the result is economic collapse.
In both cases commercial enterprises (that have "free software" for
marketing purposes) I deem unreliable.

OTOH gitee is supported by a government that has technical and
scientific progress as a first priority. The harmony os (Huawei) is
hosted there.

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 15.07.2025 um 17:25 schrieb LIT:

Now riscv is the future.

I don't know. From what I learned, RISC-V
is strongly compiler-oriented. They wrote,
for example, that it lacks any condition codes.
Only conditional branches are predicated on
examining the contents of registers at the time
of the branch. No "add with carry" nor "subtract
with carry". From an assembly point of view, the
lack of a carry flag is a PITA if you desire to
do multi-word mathematical manipulation of numbers.

So it seems, that the RISC-V architecture is intended
to be used by compilers generating code from high level
languages.

I read somewhere:
The standard is now managed by RISC-V International, which
has more than 3,000 members and which reported that more
than 10 billion chips containing RISC-V cores had shipped
by the end of 2022. Many implementations of RISC-V are
available, both as open-source cores and as commercial
IP products.

You call that compiler-oriented???

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 16.07.2025 um 07:21 schrieb dxf:

On 16/07/2025 12:09 pm, minforth wrote:

Am 15.07.2025 um 17:25 schrieb LIT:

Now riscv is the future.

I don't know. From what I learned, RISC-V
is strongly compiler-oriented. They wrote,
for example, that it lacks any condition codes.
Only conditional branches are predicated on
examining the contents of registers at the time
of the branch. No "add with carry" nor "subtract
with carry". From an assembly point of view, the
lack of a carry flag is a PITA if you desire to
do multi-word mathematical manipulation of numbers.

So it seems, that the RISC-V architecture is intended
to be used by compilers generating code from high level
languages.

I read somewhere:
The standard is now managed by RISC-V International, which
has more than 3,000 members and which reported that more
than 10 billion chips containing RISC-V cores had shipped
by the end of 2022. Many implementations of RISC-V are
available, both as open-source cores and as commercial
IP products.

You call that compiler-oriented???

It depends on how many are being programmed by the likes of GCC.
When ATMEL hit the market the manufacturer claimed their chips
were designed with compilers in mind. Do Arduino users program
in hand-coded assembler? Do you? It's no longer just the chip's
features and theoretical performance one has to worry about but
the compilers too.

Don't worry, be happy, visit https://riscv.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)