Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #60267 > unrolled thread

What is Forth anyway?

Back to article view | Back to comp.lang.forth

Contents

  What is Forth anyway? Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 20:31 -0700
    Re: What is Forth anyway? lehs <skydda.barnen@gmail.com> - 2017-06-03 23:05 -0700
      Re: What is Forth anyway? Howerd <howerdo@yahoo.co.uk> - 2017-06-04 03:23 -0700
        Re: What is Forth anyway? lehs <skydda.barnen@gmail.com> - 2017-06-04 03:39 -0700
    Re: What is Forth anyway? Howerd <howerdo@yahoo.co.uk> - 2017-06-04 03:17 -0700
      Re: What is Forth anyway? Howerd <howerdo@yahoo.co.uk> - 2017-06-04 03:18 -0700
    What is Forth anyway? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-06-04 05:17 -0700
      Re: What is Forth anyway? Howerd <howerdo@yahoo.co.uk> - 2017-06-04 07:13 -0700
      Re: What is Forth anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 02:38 -0500
    Re: What is Forth anyway? NN <november.nihal@gmail.com> - 2017-06-04 05:27 -0700
    Re: What is Forth anyway? "HAA" <someone@microsoft.com> - 2017-06-04 23:07 +1000
      Re: What is Forth anyway? Alex <alex@rivadpm.com> - 2017-06-04 19:12 +0100
        Re: What is Forth anyway? Howerd <howerdo@yahoo.co.uk> - 2017-06-04 12:55 -0700
          Re: What is Forth anyway? Alex <alex@rivadpm.com> - 2017-06-04 21:41 +0100
          Re: What is Forth anyway? "HAA" <someone@microsoft.com> - 2017-06-05 15:54 +1000
            Re: What is Forth anyway? Howerd <howerdo@yahoo.co.uk> - 2017-06-05 02:05 -0700
        Re: What is Forth anyway? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-06-04 17:33 -0700
          Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-05 12:54 +0000
      Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-04 22:14 +0000
        Re: What is Forth anyway? hughaguilar96@gmail.com - 2017-06-04 16:39 -0700
          Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-05 12:44 +0000
            Re: What is Forth anyway? hughaguilar96@gmail.com - 2017-06-05 08:10 -0700
              Re: What is Forth anyway? gavino himself <jackvanc3@gmail.com> - 2017-06-05 10:01 -0700
              Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-05 19:29 +0000
                Re: What is Forth anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-06 03:44 -0500
                  Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:26 +0000
                    Re: What is Forth anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 02:06 -0500
                      Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:09 +0000
              Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-05 19:41 +0000
                Re: What is Forth anyway? lehs <skydda.barnen@gmail.com> - 2017-06-06 02:19 -0700
                  Re: What is Forth anyway? Alex <alex@rivadpm.com> - 2017-06-06 10:41 +0100
                    Re: What is Forth anyway? Ron Aaron <rambamist@gmail.com> - 2017-06-06 12:45 +0300
                      Re: What is Forth anyway? Alex <alex@rivadpm.com> - 2017-06-06 11:23 +0100
                        Re: What is Forth anyway? Ron Aaron <rambamist@gmail.com> - 2017-06-06 13:30 +0300
                          Re: What is Forth anyway? Alex <alex@rivadpm.com> - 2017-06-06 12:55 +0100
                            Re: What is Forth anyway? Ron Aaron <rambamist@gmail.com> - 2017-06-06 14:57 +0300
                      Re: What is Forth anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-06 13:34 +0000
                        Re: What is Forth anyway? Ron Aaron <rambamist@gmail.com> - 2017-06-06 17:07 +0300
                        Re: What is Forth anyway? Coos Haak <htrofhc@gmail.com> - 2017-06-06 16:51 +0200
                          Re: What is Forth anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-06 16:32 +0000
                            Re: What is Forth anyway? Coos Haak <htrofhc@gmail.com> - 2017-06-07 01:37 +0200
                      Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:29 +0000
                        Re: What is Forth anyway? Cecil Bayona <cbayona@cbayona.com> - 2017-06-07 14:56 -0500
                  Re: What is Forth anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-06 04:48 -0500
                  Re: What is Forth anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-06 10:10 +0000
                  Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:28 +0000
                    Re: What is Forth anyway? Cecil Bayona <cbayona@cbayona.com> - 2017-06-07 14:54 -0500
                    Re: What is Forth anyway? lehs <skydda.barnen@gmail.com> - 2017-06-07 19:42 -0700
                      Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:12 +0000
        Re: What is Forth anyway? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-06-04 17:40 -0700
          Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-05 12:51 +0000
            Re: What is Forth anyway? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-06-05 17:19 -0700
              Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:32 +0000
                Re: What is Forth anyway? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-06-07 16:50 -0700
                  Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:15 +0000
                    Re: What is Forth anyway? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-06-09 13:04 -0700
                      Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 21:27 +0000
            Re: What is Forth anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-06 10:19 +0000
              Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:38 +0000
                Re: What is Forth anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-08 11:52 +0000
                  Re: What is Forth anyway? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:23 +0000
    Re: What is Forth anyway? gavino himself <jackvanc3@gmail.com> - 2017-06-05 07:16 -0700
    Re: What is Forth anyway? gavino himself <jackvanc3@gmail.com> - 2017-06-05 07:35 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#60337

hughaguilar96@gmail.com wrote:

> For a long time, I thought of Forth as being an over-grown
> macro-assembler. Most macro-assemblers have a rather prickly macro
> language, but Forth is much easier and much more powerful. Also, the
> data-stack provides a convenient way to pass parameters in and out of
> functions --- much better than using registers, and then having to
> save and restore them to the return-stack --- you have the same
> number of memory accesses, but much cleaner code, although you do
> have to dedicate a register to the data-stack-pointer.

But it also requires quite a lot of stack juggling, which is not
required with registers. I am not sure if you have the same number of
memory accesses without a stack, especially if dat can be passed in
registers directly.

Doesn't take away that the apparently prevailing notion here that
libraries are useless because they contain too much stuff you don't
need smells much like a NIH syndrome.
-- 
Rudy Velthuis        http://www.rvelthuis.de

"It's dangerous to underestimate the intelligence of a customer
 who grew a business that's successful enough to require a large
 and complex set of software" -- Grady Booch

[toc] | [prev] | [next] | [standalone]

#60345

On Monday, June 5, 2017 at 5:44:52 AM UTC-7, Rudy Velthuis wrote:
> hughaguilar96@gmail.com wrote:
> 
> > For a long time, I thought of Forth as being an over-grown
> > macro-assembler. Most macro-assemblers have a rather prickly macro
> > language, but Forth is much easier and much more powerful. Also, the
> > data-stack provides a convenient way to pass parameters in and out of
> > functions --- much better than using registers, and then having to
> > save and restore them to the return-stack --- you have the same
> > number of memory accesses, but much cleaner code, although you do
> > have to dedicate a register to the data-stack-pointer.
> 
> But it also requires quite a lot of stack juggling, which is not
> required with registers. I am not sure if you have the same number of
> memory accesses without a stack, especially if dat can be passed in
> registers directly.

Thank you very much, Captain Obvious!

You are the same guy who was previously trying to teach me how COW (copy-on-write) works, on the assumption that I was totally ignorant of the subject --- if you had looked at my STRING-STACK.4TH first, you would have noticed that COW is the primary feature, but of course you didn't have time to learn anything about the subject before commenting on it --- the internet is full of people who want to assume stupidity and ignorance on the part of everybody else, so they can promote themselves into a teacher position!

> Doesn't take away that the apparently prevailing notion here that
> libraries are useless because they contain too much stuff you don't
> need smells much like a NIH syndrome.

I'm dubious of the need for a standard Forth on micro-controllers, because the programs aren't going to be portable anyway due to hardware dependency.

I think there is a need for a standard Forth on desktop-computers though --- that is what Straight Forth is intended to be.

In Charles Moore's day (up until 1982 when he got kicked out Forth Inc.), there was little or no distinction between micro-controllers and desktop-computers. The same processors (6502 and Z80) were used in both. Operating systems, cheerfully allowed the application programmer to access the hardware directly for speed.

All of those MS-DOS compatible computers needed to be compatible at the hardware level, using the same video cards, etc. --- that was pretty primitive, and I don't know of anybody who is nostalgic for MS-DOS today ---
some folks are nostalgic for the Commodore-64, but that was a game computer, and every programmer wrote games as a teenager.

[toc] | [prev] | [next] | [standalone]

#60349

On Monday, June 5, 2017 at 11:10:19 AM UTC-4, hughag...@gmail.com wrote:
> On Monday, June 5, 2017 at 5:44:52 AM UTC-7, Rudy Velthuis wrote:
> > hughaguilar96@gmail.com wrote:
> > 
> > > For a long time, I thought of Forth as being an over-grown
> > > macro-assembler. Most macro-assemblers have a rather prickly macro
> > > language, but Forth is much easier and much more powerful. Also, the
> > > data-stack provides a convenient way to pass parameters in and out of
> > > functions --- much better than using registers, and then having to
> > > save and restore them to the return-stack --- you have the same
> > > number of memory accesses, but much cleaner code, although you do
> > > have to dedicate a register to the data-stack-pointer.
> > 
> > But it also requires quite a lot of stack juggling, which is not
> > required with registers. I am not sure if you have the same number of
> > memory accesses without a stack, especially if dat can be passed in
> > registers directly.
> 
> Thank you very much, Captain Obvious!
> 
> You are the same guy who was previously trying to teach me how COW (copy-on-write) works, on the assumption that I was totally ignorant of the subject --- if you had looked at my STRING-STACK.4TH first, you would have noticed that COW is the primary feature, but of course you didn't have time to learn anything about the subject before commenting on it --- the internet is full of people who want to assume stupidity and ignorance on the part of everybody else, so they can promote themselves into a teacher position!
> 
> > Doesn't take away that the apparently prevailing notion here that
> > libraries are useless because they contain too much stuff you don't
> > need smells much like a NIH syndrome.
> 
> I'm dubious of the need for a standard Forth on micro-controllers, because the programs aren't going to be portable anyway due to hardware dependency.
> 
> I think there is a need for a standard Forth on desktop-computers though --- that is what Straight Forth is intended to be.
> 
> In Charles Moore's day (up until 1982 when he got kicked out Forth Inc.), there was little or no distinction between micro-controllers and desktop-computers. The same processors (6502 and Z80) were used in both. Operating systems, cheerfully allowed the application programmer to access the hardware directly for speed.
> 
> All of those MS-DOS compatible computers needed to be compatible at the hardware level, using the same video cards, etc. --- that was pretty primitive, and I don't know of anybody who is nostalgic for MS-DOS today ---
> some folks are nostalgic for the Commodore-64, but that was a game computer, and every programmer wrote games as a teenager.

http://www.happstack.com/page/view-page-slug/5/happstack-philosophy

the 100 node app thing is still something it seems only java cancer is trying to attack
(unless you count plan9)
www.hypertable.org
https://spark.apache.org/
http://mesos.apache.org/

[toc] | [prev] | [next] | [standalone]

#60357

hughaguilar96@gmail.com wrote:

> On Monday, June 5, 2017 at 5:44:52 AM UTC-7, Rudy Velthuis wrote:
> > hughaguilar96@gmail.com wrote:
> > 
> > > For a long time, I thought of Forth as being an over-grown
> > > macro-assembler. Most macro-assemblers have a rather prickly macro
> > > language, but Forth is much easier and much more powerful. Also,
> > > the data-stack provides a convenient way to pass parameters in
> > > and out of functions --- much better than using registers, and
> > > then having to save and restore them to the return-stack --- you
> > > have the same number of memory accesses, but much cleaner code,
> > > although you do have to dedicate a register to the
> > > data-stack-pointer.
> > 
> > But it also requires quite a lot of stack juggling, which is not
> > required with registers. I am not sure if you have the same number
> > of memory accesses without a stack, especially if dat can be passed
> > in registers directly.
> 
> Thank you very much, Captain Obvious!

It may be obvious, but it also shows why stack based passing is not so
optimal as you claim it to be. It is nice concept, but I doubt it is
the most efficient way to pass parameters. After all, it used to be the
main way to pass parameters in most other languages too. But these
had/have ways to access each of them by name, not just the one(s) on
the top of the stack.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Violence is the last refuge of the incompetent." -- Issac Asimov

[toc] | [prev] | [next] | [standalone]

#60366

Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
>> > 
>> > But it also requires quite a lot of stack juggling, which is not
>> > required with registers. I am not sure if you have the same number
>> > of memory accesses without a stack, especially if dat can be passed
>> > in registers directly.
>> 
>> Thank you very much, Captain Obvious!
> 
> It may be obvious, but it also shows why stack based passing is not
> so optimal as you claim it to be. It is nice concept, but I doubt it
> is the most efficient way to pass parameters. After all, it used to
> be the main way to pass parameters in most other languages too. But
> these had/have ways to access each of them by name, not just the
> one(s) on the top of the stack.

That's all true, but there are disadvantages too.

If I've already paid for those registers, which require large and
complex electronics, I probably also have multiple functional units
and instructions per clock, so I might as well use them all as much as
possible.  All other things being equal, that is, but they rarely are!

To translate any programming language into near-optimum code for a
register machine is a hard problem.  And I'm going to end up with a
lot of software to do that.  You might say that well, you were only
talking about parameter passing, not allocation in general, and that's
true.  But to do parameter passing in registers in a way that is
reasonably efficient takes a good register allocator or I'm going to
have a great deal of thrashing.  Sure, I can probably get away with a
simple linear scan register allocator but even that's pretty complex.

I might decide to do something fairly simple instead of allocating
registers, and concentrate my efforts on the 10% of the software that
I need to optimize to hit my goals.  Is that going to win any
benchmark wars?  No.

Andrew.

[toc] | [prev] | [next] | [standalone]

#60433

Andrew Haley wrote:

> Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
> >> > 
> >> > But it also requires quite a lot of stack juggling, which is not
> >> > required with registers. I am not sure if you have the same
> number >> > of memory accesses without a stack, especially if dat can
> be passed >> > in registers directly.
> >> 
> >> Thank you very much, Captain Obvious!
> > 
> > It may be obvious, but it also shows why stack based passing is not
> > so optimal as you claim it to be. It is nice concept, but I doubt it
> > is the most efficient way to pass parameters. After all, it used to
> > be the main way to pass parameters in most other languages too. But
> > these had/have ways to access each of them by name, not just the
> > one(s) on the top of the stack.
> 
> That's all true, but there are disadvantages too.
> 
> If I've already paid for those registers, which require large and
> complex electronics, I probably also have multiple functional units
> and instructions per clock, so I might as well use them all as much as
> possible.  All other things being equal, that is, but they rarely are!
> 
> To translate any programming language into near-optimum code for a
> register machine is a hard problem.  And I'm going to end up with a
> lot of software to do that.

Oh? Why are you going to end up with a lot of software to do that?
Parameter passing is generally governed by ABIs or calling conventions.
There is no need to allocate registers for that.

And parameter passing through a stack is also governed by a certain
order. Why would that be more optimal, especially if you must do extra
work to access anything but the top of the stack and to prevent values
from being consumed? What makes random access to such a stack (like in
older versions of popular programming languages, which use the machine
stack to pass parameters) harder to use?

Sure, you must have a good register allocator to be able to keep as
many values in registers. But how is that different for a stack based
language? Forth stacks are, as far as I know, generally in memory, like
local variables and parameters in other non-stack-based languages, who
also, most of the time, live on a stack (the machine stack).

And yes, I know there are optimizing Forth implementations. But I
assume these have a register allocator too, and don't constantly push
and pop items. That probably means they need "a lot of software" too,
or do they?

So I still don't see why parameter passing, or register allocation is
easier or more optimal in a stack based language.

I personally find random access to values like parameters or local
variables easier to handle than stack juggling. No need for the
constant use of DUP (or ?DUP) or OVER (in other words: copying), etc.
in order to keep a value from being consumed (and lost). Sure, you can
rearrange your  code so that you avoid some of it. But that also
requires extra effort from the programmer.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"I don't care to belong to a club that accepts people like me as
 members." -- Groucho Marx

[toc] | [prev] | [next] | [standalone]

#60454

Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
> Andrew Haley wrote:
> 
>> Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
>> >> > 
>> >> > But it also requires quite a lot of stack juggling, which is not
>> >> > required with registers. I am not sure if you have the same
>> number >> > of memory accesses without a stack, especially if dat can
>> be passed >> > in registers directly.
>> >> 
>> >> Thank you very much, Captain Obvious!
>> > 
>> > It may be obvious, but it also shows why stack based passing is not
>> > so optimal as you claim it to be. It is nice concept, but I doubt it
>> > is the most efficient way to pass parameters. After all, it used to
>> > be the main way to pass parameters in most other languages too. But
>> > these had/have ways to access each of them by name, not just the
>> > one(s) on the top of the stack.
>> 
>> That's all true, but there are disadvantages too.
>> 
>> If I've already paid for those registers, which require large and
>> complex electronics, I probably also have multiple functional units
>> and instructions per clock, so I might as well use them all as much as
>> possible.  All other things being equal, that is, but they rarely are!
>> 
>> To translate any programming language into near-optimum code for a
>> register machine is a hard problem.  And I'm going to end up with a
>> lot of software to do that.
> 
> Oh? Why are you going to end up with a lot of software to do that?
> Parameter passing is generally governed by ABIs or calling conventions.
> There is no need to allocate registers for that.
> 
> And parameter passing through a stack is also governed by a certain
> order. Why would that be more optimal, especially if you must do extra
> work to access anything but the top of the stack and to prevent values
> from being consumed?

A Forth compiler doesn't need to do any extra work.

> What makes random access to such a stack (like in older versions of
> popular programming languages, which use the machine stack to pass
> parameters) harder to use?

Forth doesn't use random access to the stack.  (Except PICK and ROLL,
but bleurgh.)

> Sure, you must have a good register allocator to be able to keep as
> many values in registers. But how is that different for a stack based
> language?

Stack allocation is trivial because you can have as many stack slots
as you want.  Register allocation is hard because there is a fixed
number of them, and there is a lot of shuffling to be done when you
run out.

> Forth stacks are, as far as I know, generally in memory, like local
> variables and parameters in other non-stack-based languages, who
> also, most of the time, live on a stack (the machine stack).
> 
> And yes, I know there are optimizing Forth implementations. But I
> assume these have a register allocator too, and don't constantly push
> and pop items. That probably means they need "a lot of software" too,
> or do they?

Yes, they do.  To take advantage of registers for parameter passing,
you need a way to allocate them efficiently: if you don't do that
you're going to have lot of moves at every call site.  On the other
hand, stack allocation is trivial.

> So I still don't see why parameter passing, or register allocation is
> easier or more optimal in a stack based language.

Stack allocation is certainly easier: when you want a lot to use, you
push it on the top.  Register allocation, not so much.

> I personally find random access to values like parameters or local
> variables easier to handle than stack juggling.

It's not a matter of what you personally find, but what a compiler has
to do.

Andrew.

[toc] | [prev] | [next] | [standalone]

#60508

Andrew Haley wrote:

> Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
> > Andrew Haley wrote:
> > 
> >> Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
> >> >> > 
> >> >> > But it also requires quite a lot of stack juggling, which is
> not >> >> > required with registers. I am not sure if you have the
> same >> number >> > of memory accesses without a stack, especially if
> dat can >> be passed >> > in registers directly.
> >> >> 
> >> >> Thank you very much, Captain Obvious!
> >> > 
> >> > It may be obvious, but it also shows why stack based passing is
> not >> > so optimal as you claim it to be. It is nice concept, but I
> doubt it >> > is the most efficient way to pass parameters. After
> all, it used to >> > be the main way to pass parameters in most other
> languages too. But >> > these had/have ways to access each of them by
> name, not just the >> > one(s) on the top of the stack.
> >> 
> >> That's all true, but there are disadvantages too.
> >> 
> >> If I've already paid for those registers, which require large and
> >> complex electronics, I probably also have multiple functional units
> >> and instructions per clock, so I might as well use them all as
> much as >> possible.  All other things being equal, that is, but they
> rarely are!  >> 
> >> To translate any programming language into near-optimum code for a
> >> register machine is a hard problem.  And I'm going to end up with a
> >> lot of software to do that.
> > 
> > Oh? Why are you going to end up with a lot of software to do that?
> > Parameter passing is generally governed by ABIs or calling
> > conventions.  There is no need to allocate registers for that.
> > 
> > And parameter passing through a stack is also governed by a certain
> > order. Why would that be more optimal, especially if you must do
> > extra work to access anything but the top of the stack and to
> > prevent values from being consumed?
> 
> A Forth compiler doesn't need to do any extra work.
> 
> > What makes random access to such a stack (like in older versions of
> > popular programming languages, which use the machine stack to pass
> > parameters) harder to use?
> 
> Forth doesn't use random access to the stack.  (Except PICK and ROLL,
> but bleurgh.)
> 
> > Sure, you must have a good register allocator to be able to keep as
> > many values in registers. But how is that different for a stack
> > based language?
> 
> Stack allocation is trivial because you can have as many stack slots
> as you want.  Register allocation is hard because there is a fixed
> number of them, and there is a lot of shuffling to be done when you
> run out.
> 
> > Forth stacks are, as far as I know, generally in memory, like local
> > variables and parameters in other non-stack-based languages, who
> > also, most of the time, live on a stack (the machine stack).
> > 
> > And yes, I know there are optimizing Forth implementations. But I
> > assume these have a register allocator too, and don't constantly
> > push and pop items. That probably means they need "a lot of
> > software" too, or do they?
> 
> Yes, they do.  To take advantage of registers for parameter passing,
> you need a way to allocate them efficiently: if you don't do that
> you're going to have lot of moves at every call site.  On the other
> hand, stack allocation is trivial.

I don't see what is more trivial about it. Or alternatively, it puts a
much higher burden on the programmer, because the programmer must do
the stack juggling (oftentimes involving a lot of copying). And I
rather have most of my values in registers than in memory.
 
> > So I still don't see why parameter passing, or register allocation
> > is easier or more optimal in a stack based language.
> 
> Stack allocation is certainly easier: when you want a lot to use, you
> push it on the top.  Register allocation, not so much.

In non-stack-based languages, local variables are easily accessed and
easily allocated: just one change of the stack pointer. No stack
juggling required. No constant push/pops.
> 
> > I personally find random access to values like parameters or local
> > variables easier to handle than stack juggling.
> 
> It's not a matter of what you personally find, but what a compiler has
> to do.

Yes, indeed. It is easier for the compiler if it can do random access
to (local) variables and parameters than if it must do this in a LIFO
way.
-- 
Rudy Velthuis        http://www.rvelthuis.de

"A most important, but also most elusive, aspect of any tool is
 its influence on the habits of those who train themselves in its
 use. If the tool is a programming language this influence is, 
 whether we like it or not, an influence on our thinking habits." 
 -- Edsger Dijkstra

[toc] | [prev] | [next] | [standalone]

#60358

hughaguilar96@gmail.com wrote:

> > But it also requires quite a lot of stack juggling, which is not
> > required with registers. I am not sure if you have the same number
> > of memory accesses without a stack, especially if dat can be passed
> > in registers directly.
> 
> Thank you very much, Captain Obvious!

You are welcome.
 
> You are the same guy who was previously trying to teach me how COW
> (copy-on-write) works, on the assumption that I was totally ignorant
> of the subject

Well, you made some silly claims about it, IIRC (I really don't quite
remember what it was about, but I guess it was about your string stack,
once again). Oh wait, you complained about the need to do a lot of
copying or some such, right?

And you are the same guy who tends to get rather rude about certain
people here. I remember that.

> if you had looked at my STRING-STACK.4TH first, you would have noticed
> that COW is the primary feature, but of course you didn't have time
to
> learn anything about the subject before commenting on it

I absolutely don't care about your string stack. I have no need for it.

But if I remember correctly, you made some silly claims about the need
to do a lot of copying in certain situations. I merely reacted to that
and mentioned COW and how I use it. I don't know if you use COW or how
you manage your strings and I am certainly not trying to teach anyone.
Why should I?

And I don't know nor care if you are stupid or not (I generally assume
people know what they are talking about, even if, on the internet, that
is not a given).

I do know you are rude, oftentimes.
-- 
Rudy Velthuis        http://www.rvelthuis.de

"When encountering a new philosophy or religion, do not
 convert, but rather assimilate."
 -- Shawn Mikula

[toc] | [prev] | [next] | [standalone]

#60369

Den måndag 5 juni 2017 kl. 21:41:50 UTC+2 skrev Rudy Velthuis:
> hughaguilar96@gmail.com wrote:
> 
> > > But it also requires quite a lot of stack juggling, which is not
> > > required with registers. I am not sure if you have the same number
> > > of memory accesses without a stack, especially if dat can be passed
> > > in registers directly.
> > 
> > Thank you very much, Captain Obvious!
> 
> You are welcome.
>  
> > You are the same guy who was previously trying to teach me how COW
> > (copy-on-write) works, on the assumption that I was totally ignorant
> > of the subject
> 
> Well, you made some silly claims about it, IIRC (I really don't quite
> remember what it was about, but I guess it was about your string stack,
> once again). Oh wait, you complained about the need to do a lot of
> copying or some such, right?
> 
> And you are the same guy who tends to get rather rude about certain
> people here. I remember that.
> 
> > if you had looked at my STRING-STACK.4TH first, you would have noticed
> > that COW is the primary feature, but of course you didn't have time
> to
> > learn anything about the subject before commenting on it
> 
> I absolutely don't care about your string stack. I have no need for it.
> 
> But if I remember correctly, you made some silly claims about the need
> to do a lot of copying in certain situations. I merely reacted to that
> and mentioned COW and how I use it. I don't know if you use COW or how
> you manage your strings and I am certainly not trying to teach anyone.
> Why should I?
> 
> And I don't know nor care if you are stupid or not (I generally assume
> people know what they are talking about, even if, on the internet, that
> is not a given).
> 
> I do know you are rude, oftentimes.
> -- 
> Rudy Velthuis        http://www.rvelthuis.de
> 
> "When encountering a new philosophy or religion, do not
>  convert, but rather assimilate."
>  -- Shawn Mikula

How much faster would Forth become with maybe hundreds of highly optimized stack juggling words, like under+, over+, tuck+, underdup, underswap,....... which almost made juggling word combinations unnecessary?

I don't think Forth has to be the fastest language, but it need to be better than slow. Fast coding and modular structures are worth as much as optimized speed in a lot of applications.

[toc] | [prev] | [next] | [standalone]

#60371

On 6/6/2017 10:19, lehs wrote:
> How much faster would Forth become with maybe hundreds of highly
> optimized stack juggling words, like under+, over+, tuck+, underdup,
> underswap,....... which almost made juggling word combinations
> unnecessary?

Not very; probably a lot slower. The best strategy is to eliminate them 
through stack management, something that most human programmers are poor 
to ok at, but an activity where machines can excel. Optimizing compilers 
are much better and more consistent at this. Although the word optimize 
tends to generate a "it's not what the programmer wrote" reaction from 
some here.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#60372

On 06/06/17 12:41, Alex wrote:

> Although the word optimize
> tends to generate a "it's not what the programmer wrote" reaction from
> some here.

I suppose I'm in that camp.

Even though (for example) eliminating "DUP DROP" would normally be
considered a "safe optimization", how is the compiler to know if the
programmer *intended* that due to side-effects?

[toc] | [prev] | [next] | [standalone]

#60377

On 6/6/2017 10:45, Ron Aaron wrote:
> 
> 
> On 06/06/17 12:41, Alex wrote:
> 
>> Although the word optimize
>> tends to generate a "it's not what the programmer wrote" reaction from
>> some here.
> 
> I suppose I'm in that camp.
> 
> Even though (for example) eliminating "DUP DROP" would normally be
> considered a "safe optimization", how is the compiler to know if the
> programmer *intended* that due to side-effects?
> 

What side effects? And forget the compiler, what is the reader of such a 
thing meant to deduce from it?

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#60378

On 06/06/17 13:23, Alex wrote:
> On 6/6/2017 10:45, Ron Aaron wrote:

>> Even though (for example) eliminating "DUP DROP" would normally be
>> considered a "safe optimization", how is the compiler to know if the
>> programmer *intended* that due to side-effects?
>>
> 
> What side effects? And forget the compiler, what is the reader of such a
> thing meant to deduce from it?

The *reader* should be able to see a comment explaining why that
sequence is there, and what the side-effects are which require it.

Perhaps it's for a timing loop, or cache-clearing or who knows what?

A better example might be a "@ !" combo, which also nominally "does
nothing" but may have specifically desired effects on some hardware.

[toc] | [prev] | [next] | [standalone]

#60380

On 6/6/2017 11:30, Ron Aaron wrote:
> 
> 
> On 06/06/17 13:23, Alex wrote:
>> On 6/6/2017 10:45, Ron Aaron wrote:
> 
>>> Even though (for example) eliminating "DUP DROP" would normally be
>>> considered a "safe optimization", how is the compiler to know if the
>>> programmer *intended* that due to side-effects?
>>>
>>
>> What side effects? And forget the compiler, what is the reader of such a
>> thing meant to deduce from it?
> 
> The *reader* should be able to see a comment explaining why that
> sequence is there, and what the side-effects are which require it.
> 
> Perhaps it's for a timing loop, or cache-clearing or who knows what?
> 
> A better example might be a "@ !" combo, which also nominally "does
> nothing" but may have specifically desired effects on some hardware.
> 

Comments come in all shapes and sizes. Do it formally.

opt off
: dirty dup @ swap ! ; \ dirty the page
opt on

Now readers and compilers know for certain.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#60381

On 06/06/2017 14:55, Alex wrote:

> Comments come in all shapes and sizes. Do it formally.
> 
> opt off
> : dirty dup @ swap ! ; \ dirty the page
> opt on
> 
> Now readers and compilers know for certain.

Fair enough.

[toc] | [prev] | [next] | [standalone]

#60389

Ron Aaron <rambamist@gmail.com> writes:
>Even though (for example) eliminating "DUP DROP" would normally be
>considered a "safe optimization", how is the compiler to know if the
>programmer *intended* that due to side-effects?

In Gforth, we actually have a visible side effect of that:

[b8:~/gforth:16424] gforth
Gforth 0.7.9_20170406, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
: foo dup drop ;  ok
foo 
*the terminal*:2: error: Stack underflow
foo
Backtrace:
                                         0 $7FB6F17E1350 dup 

I very much doubt that any programmer actually *intends* this side
effect.  However, when developing a program, they probably find it
convenient to be notified of a stack underflow at the earliest
opportunity, and that is why the debugging engine "gforth" disables
stack caching completely: it would mask the stack underflow.  There is
the benchmarking engine gforth-fast, which performs stack caching and
masks this bug:

[b8:~/gforth:16425] gforth-fast
Gforth 0.7.9_20170406, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
: foo dup drop ;  ok
foo  ok

So, the answer to this question is: The compiler knows because the
user actually called the appropriate compiler for his usage
requirements.

- 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 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#60391

On 06/06/2017 16:34, Anton Ertl wrote:
> Ron Aaron <rambamist@gmail.com> writes:
>> Even though (for example) eliminating "DUP DROP" would normally be
>> considered a "safe optimization", how is the compiler to know if the
>> programmer *intended* that due to side-effects?
> 
> In Gforth, we actually have a visible side effect of that:
> 
> [b8:~/gforth:16424] gforth
> Gforth 0.7.9_20170406, Copyright (C) 1995-2016 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `help' for basic help
> : foo dup drop ;  ok
> foo 
> *the terminal*:2: error: Stack underflow
> foo
> Backtrace:
>                                          0 $7FB6F17E1350 dup 

8th does something similar:
dup drop

Exception: stack empty: at offset 4 in console: dup (G:;;; +000000f6)
Exception: stack empty: at offset 9 in console: drop (G:;;; +000000f6)


> 
> I very much doubt that any programmer actually *intends* this side
> effect.  However, when developing a program, they probably find it
> convenient to be notified of a stack underflow at the earliest
> opportunity, and that is why the debugging engine "gforth" disables
> stack caching completely: it would mask the stack underflow.  There is
> the benchmarking engine gforth-fast, which performs stack caching and
> masks this bug:
> 
> [b8:~/gforth:16425] gforth-fast
> Gforth 0.7.9_20170406, Copyright (C) 1995-2016 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `help' for basic help
> : foo dup drop ;  ok
> foo  ok
> 
> So, the answer to this question is: The compiler knows because the
> user actually called the appropriate compiler for his usage
> requirements.

Hmm.  Well, the Compiler I suppose (rather than user)...

[toc] | [prev] | [next] | [standalone]

#60393

Op Tue, 06 Jun 2017 13:34:34 GMT schreef Anton Ertl:

> Ron Aaron <rambamist@gmail.com> writes:
>>Even though (for example) eliminating "DUP DROP" would normally be
>>considered a "safe optimization", how is the compiler to know if the
>>programmer *intended* that due to side-effects?
> 
> In Gforth, we actually have a visible side effect of that:
> 
> [b8:~/gforth:16424] gforth
> Gforth 0.7.9_20170406, Copyright (C) 1995-2016 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `help' for basic help
>: foo dup drop ;  ok
> foo 
> *the terminal*:2: error: Stack underflow
> foo
> Backtrace:
>                                          0 $7FB6F17E1350 dup 
> 
> I very much doubt that any programmer actually *intends* this side
> effect.  However, when developing a program, they probably find it
> convenient to be notified of a stack underflow at the earliest
> opportunity, and that is why the debugging engine "gforth" disables
> stack caching completely: it would mask the stack underflow.  There is
> the benchmarking engine gforth-fast, which performs stack caching and
> masks this bug:
> 
> [b8:~/gforth:16425] gforth-fast
> Gforth 0.7.9_20170406, Copyright (C) 1995-2016 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `help' for basic help
>: foo dup drop ;  ok
> foo  ok
> 
> So, the answer to this question is: The compiler knows because the
> user actually called the appropriate compiler for his usage
> requirements.
> 
> - anton

I could not reproduce this:

$ gforth
Gforth 0.7.9_20170601, Copyright (C) 1995-2016 Free Software Foundation,
Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
: foo dup drop ;  ok
foo  ok
bye

$ gforth-fast
Gforth 0.7.9_20170601, Copyright (C) 1995-2016 Free Software Foundation,
Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
: foo dup drop ;  ok
foo  ok
bye

groet Coos

[toc] | [prev] | [next] | [standalone]

#60401

Coos Haak <htrofhc@gmail.com> writes:
>Op Tue, 06 Jun 2017 13:34:34 GMT schreef Anton Ertl:
>
>> Ron Aaron <rambamist@gmail.com> writes:
>>>Even though (for example) eliminating "DUP DROP" would normally be
>>>considered a "safe optimization", how is the compiler to know if the
>>>programmer *intended* that due to side-effects?
>> 
>> In Gforth, we actually have a visible side effect of that:
>> 
>> [b8:~/gforth:16424] gforth
>> Gforth 0.7.9_20170406, Copyright (C) 1995-2016 Free Software Foundation, Inc.
>> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>> Type `help' for basic help
>>: foo dup drop ;  ok
>> foo 
>> *the terminal*:2: error: Stack underflow
...
>I could not reproduce this:
>
>$ gforth
>Gforth 0.7.9_20170601, Copyright (C) 1995-2016 Free Software Foundation,
>Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `help' for basic help
>: foo dup drop ;  ok
>foo  ok
>bye

It requires an OS that supports mmap() and mprotect(), typically any
modern Unix.

- 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 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web