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.
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
with. And ditch github (USA) in favour of gitee (Chinese).
USA is circling the drain.
albert@spenarnc.xs4all.nl writes:
with. And ditch github (USA) in favour of gitee (Chinese).
USA is circling the drain.
Try codeberg.org (Germany) maybe.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 143:39:19 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,669 |