Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]

On 16/09/2024 2:52 am, Paul Rubin wrote:

dxf <dxforth@gmail.com> writes:

Going back to the EMITS example:
>
- despite lack of comments you quickly deduced what it did
- stack operations were few and simple and still you didn't like it
- your ideal is that every stack operation should go, which is what
  you did

 
It was the first word in the program that used any stack operations at
all.  I saw that it was more concise and imho more readable without
them.  Other words there were much harder to read.
 

If one takes from forth that which makes it efficient, then one takes away
its reason for existence.  Unfortunately for forth, this is what locals
users are doing, whether they're aware of it or not.

 
I'm not persuaded that the stack ops make Forth efficient.

That's been the evidence thus far.

Certainly
not as much as advanced compilers do, and yet one of the big attractions
of Forth has been very simple interpreters.
 
On my x86-64 laptop, gcc -c -S -Os on
 
    void emit(char);
    void emits(char c, int n) {
      while (n-- > 0) emit(c);
    }
 
gives me 27 bytes, 15 instructions, beating all of the Forth examples.
Several of the 14 instructions seem related to passing parameters in
registers.  Passing on the stack like in old fashioned systems would
save a few more, at the expense of some speed.  So if I want efficiency,
I should use C.

Yes - if you want efficiency with locals use C since C is built upon a
locals paradigm.  Also modern cpu's are optimized for the likes of C.

But just because C can beat forth on a benchmark is no reason to dismiss
either Forth or efficient programming.  The weak links are the programmer
and the tools he's given.  All I ever seem to hear about other languages
is how they make life easy for the programmer.  And this is what some are
trying to bring to forth.  To hell with what they offer I say.  The universe
gave me a brain.  I intend to use it.

 

Anyway, if efficiency was important for that example, I'd use CODE.

In other words forth is not important to you.

 
I would say efficiency is usually not very important to me, whether in
forth or any other language.  It's the usual story of programs having
hot spots.  Aim for efficiency in the hot spots and readability and ease
of implementation everywhere else.
 
Also, you define "forth" as using stack ops instead of locals.  I don't
define it that way.  Forth with locals is still Forth.  They are in the
standard after all.

I don't believe in religion - the priests, the holy books, the promises.
I'll take what is and make the best of it.