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

How do you remember the stack?

Started by	laheadle@gmail.com
First post	2016-02-12 13:57 -0800
Last post	2016-02-22 01:46 -0800
Articles	20 on this page of 115 — 26 participants

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

  How do you remember the stack? laheadle@gmail.com - 2016-02-12 13:57 -0800
    Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-12 14:08 -0800
      Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-16 13:35 +1100
        Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-15 19:28 -0800
        Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-15 19:54 -0800
        Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 07:28 +0000
          Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-15 22:03 -1000
            Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 13:30 +0000
              Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-16 08:20 -1000
                Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-16 20:48 +0000
                Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-17 15:42 +0000
            Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-18 18:48 +1100
              Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-18 12:27 -0800
                Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-18 14:53 -0800
                  Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-18 15:18 -0800
                Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-21 13:32 +1100
                  Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-20 20:57 -0800
                    Re: How do you remember the stack? Ron Aaron <rambamist@gmail.com> - 2016-02-21 07:23 +0200
                      Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-21 08:54 -0800
                  Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-21 22:05 -0800
                  Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-22 16:20 +0100
                    Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-22 09:47 -0600
                    Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-23 16:51 -0800
                      Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-28 15:22 +1100
                        Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-27 21:30 -0800
                          Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-27 21:33 -0800
                        Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-27 21:39 -1000
                          Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-29 13:47 +1100
                            Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-28 19:02 -0800
                              Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-28 22:26 -0800
                                Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-28 22:37 -0800
                            Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-28 19:11 -0800
                            Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-29 11:55 -0600
                            Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-29 19:30 -1000
                              Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-03-02 00:49 +1100
                                Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-01 13:50 -1000
                                Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-03-01 16:49 -0800
                                  Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-03-01 18:04 -0800
                                  Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-02 02:53 -0600
                                  Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 09:57 +0000
                                    Re: How do you remember the stack? Pablo Hugo Reda <pabloreda@gmail.com> - 2016-03-02 03:21 -0800
                                      Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 11:49 +0000
                                        Re: How do you remember the stack? Pablo Hugo Reda <pabloreda@gmail.com> - 2016-03-02 04:23 -0800
                                    Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-02 18:32 +0000
                                      Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 18:41 +0000
                                        Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-02 20:36 +0000
                                        Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 07:38 +0000
                                          Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 09:26 +0000
                                            Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 11:15 +0000
                                              Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 15:35 +0000
                                                Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 15:56 +0000
                                                  Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 17:04 +0000
                                Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-03-01 19:29 -0800
                        Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-28 18:52 +0000
                        Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-28 13:30 -0800
                        Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-29 07:55 +0100
                          Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-29 19:34 -1000
                            Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-03-01 20:40 -0800
                            Re: How do you remember the stack? Unknown <dog@gmail.com> - 2016-06-02 05:46 +0000
                              Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-02 08:48 +0200
                                Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-06-02 00:17 -0700
                                Re: How do you remember the stack? Michael Barry <barrym95838@yahoo.com> - 2016-06-02 19:48 -0700
                                  Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-06-02 20:34 -0700
                  Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-02-22 19:23 +0000
                    Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-25 20:31 +1100
                      Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-25 07:44 -0800
                        Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-25 20:22 +0100
                        Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-28 13:43 +1100
                          Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-27 21:43 -1000
                            Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-28 14:53 +0000
                            Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-28 15:27 -0800
                  Re: How do you remember the stack? humptydumpty <ouatubi@gmail.com> - 2016-06-02 02:02 -0700
                  Re: How do you remember the stack? JennyB <jennybrien@googlemail.com> - 2016-06-03 05:57 -0700
        Re: How do you remember the stack? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-01 16:38 +0000
    Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-12 16:31 -0800
    Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-12 17:31 -0800
    Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-13 08:03 +0100
    Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-13 08:06 +0000
      Re: How do you remember the stack? minforth@arcor.de - 2016-02-13 01:50 -0800
        Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:22 -0800
          Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-13 17:09 +0000
        Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:39 -0800
        Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:42 -0800
        Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-13 11:27 +0000
          Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-13 12:33 +0000
            Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 01:05 -0800
        Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-14 19:34 +0000
    Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-13 06:43 -0800
      Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 01:22 -0800
        Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-15 09:48 +0000
        Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-15 09:53 +0000
          Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-15 11:26 +0000
            Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 04:53 -0800
              Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-15 17:06 +0000
                Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 14:57 +0000
            Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 14:14 +0000
        Re: How do you remember the stack? Ron Aaron <rambamist@gmail.com> - 2016-02-15 12:31 +0200
        Re: How do you remember the stack? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-02-18 22:53 +0000
    Re: How do you remember the stack? Doug Hoffman <glidedog@gmail.com> - 2016-02-13 10:51 -0500
    Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-14 10:18 +1100
    Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-14 04:21 -0600
    Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-20 14:36 -0800
      Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-21 16:35 +0000
        Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-21 18:34 +0000
          Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-22 09:52 +0000
            Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-22 13:07 +0000
              Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-22 15:41 +0000
                Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-22 08:24 -1000
              Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-22 08:21 -1000
                Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-22 17:51 -0800
                  Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-22 18:15 -0800
                  Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-02-29 06:20 +0000
                  Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-03-02 20:42 +0000
                    Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-06-02 20:13 +0000
    Re: How do you remember the stack? humptydumpty <ouatubi@gmail.com> - 2016-02-22 01:46 -0800

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

#45507

From	Albert van der Horst <albert@spenarnc.xs4all.nl>
Date	2016-02-13 17:09 +0000
Message-ID	<56bf632d$0$23775$e4fe514c@news.xs4all.nl>
In reply to	#45498

mhx@iae.nl writes:

>On Saturday, February 13, 2016 at 10:50:54 AM UTC+1, minf...@arcor.de wrote:
>> This leads me to the following silly question:
>>
>> Is there a clever algorithm that converts locals syntax to stack
>> juggling for Forths that have no locals implemented?

>The question is not silly, but imprecise.

>If one wants to take the code as is on a Forth not having locals,
>you're asking if it is possible to implement locals in high-level.
>The answer is yes, e.g. Wil Baden's solution for FP also works
>for integers.

>(If you accept that the source code is changed, it becomes
>a question of the algorithm does and what the programmer
>changes, making it a really ill-posed problem.)

>Your next move would probably be to state that you don't like
>the way this high-level solution works (it uses the dictionary
>like Wil's solution, or has an extra stack), and you constrain
>the solution by requiring it to only use the data stack.
>However, in that case the 'clever algorithm' needs to know
>the stack effect of every Forth word that is used in the word
>that you are translating. This is a feature that not many
>Forths support (LINA maybe?). As some Forth words do *not
>have* a constant stack effect (e.g. EXECUTE), your 'clever
>algorithm' is turning into something that is many times
>bigger and complicated than the problem you wanted to
>solve (and it would force you to switch to Lina). As
>that is not Forth-like, you would drop the constraint and
>use, e.g., Wil Baden's solution, probably combined with
>Anton Ertl's ideas in anslocal.fs to allow arbitrary names.

Regards lina. The official lina does not know the stack effect of
words.  There was an experiment where knowledge of
stack effect was added, in behalf of optimisation.
That is probably what marcel is referring to.

<SNIP>

>-marcel
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#45500

From	mhx@iae.nl
Date	2016-02-13 03:39 -0800
Message-ID	<7474af8c-b530-4a46-a955-9268edb4875a@googlegroups.com>
In reply to	#45496

On Saturday, February 13, 2016 at 10:50:54 AM UTC+1, minf...@arcor.de wrote:
> This leads me to the following silly question:
>
> Is there a clever algorithm that converts locals syntax to stack
> juggling for Forths that have no locals implemented?

The question is not silly, but imprecise.

If one wants to take the code as is on a Forth not having locals,
you're asking if it is possible to implement locals in high-level.
The answer is yes, e.g. Wil Baden's solution for FP also works
for integers.

(If you accept that the source code is changed, it becomes
a question of the algorithm does and what the programmer
changes, making it a really ill-posed problem.)

Your next move would probably be to state that you don't like
the way this high-level solution works (it uses the dictionary
like Wil's solution, or has an extra stack), and you constrain
the solution by requiring it to only use the data stack.
However, in that case the 'clever algorithm' needs to know
the stack effect of every Forth word that is used in the word
that you are translating. This is a feature that not many
Forths support (LINA maybe?). As some Forth words do *not
have* a constant stack effect (e.g. EXECUTE), your 'clever
algorithm' is turning into something that is many times
bigger and complicated than the problem you wanted to
solve (and it would force you to switch to Lina). As
that is not Forth-like, you would drop the constraint and
use, e.g., Wil Baden's solution, probably combined with
Anton Ertl's ideas in anslocal.fs to allow arbitrary names.

The optimizing Forth compilers I know have a locals
stack, but when they can figure out that the CPU
has enough resources to fit everything in
registers they don't use it. In doing that,
they also remove most or all data stack
manipulations. In a sense that is a solution
that fits your requirement + constraint, but
I am sure you also don't want to hear this
possibility :-)

-marcel

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

#45501

From	mhx@iae.nl
Date	2016-02-13 03:42 -0800
Message-ID	<a8313df4-b256-4d2d-a78a-89c4fbd1fbd3@googlegroups.com>
In reply to	#45496

On Saturday, February 13, 2016 at 10:50:54 AM UTC+1, minf...@arcor.de wrote:
> This leads me to the following silly question:
>
> Is there a clever algorithm that converts locals syntax to stack
> juggling for Forths that have no locals implemented?

The question is not silly, but imprecise.

If one wants to take the code as is on a Forth not having locals,
you're asking if it is possible to implement locals in high-level.
The answer is yes, e.g. Wil Baden's solution for FP also works
for integers.

(If you accept that the source code is changed, it becomes
a question of what the algorithm does and what the programmer
changes, making it a really ill-posed problem.)

Your next move would probably be to state that you don't like
the way this high-level solution works (it uses the dictionary
like Wil's solution, or has an extra stack), and you constrain
the solution by requiring it to only use the data stack.
However, in that case the 'clever algorithm' needs to know
the stack effect of every Forth word that is used in the word
that you are translating. This is a feature that not many
Forths support (LINA maybe?). As some Forth words do *not
have* a constant stack effect (e.g. EXECUTE), your 'clever
algorithm' is turning into something that is many times
bigger and complicated than the problem you wanted to
solve (and it would force you to switch to Lina). As
that is not Forth-like, you would drop the constraint and
use, e.g., Wil Baden's solution, probably combined with
Anton Ertl's ideas in anslocal.fs to allow arbitrary names.

The optimizing Forth compilers I know have a locals
stack, but when they can figure out that the CPU
has enough resources to fit everything in
registers they don't use it. In doing that,
they also remove most or all data stack
manipulations. In a sense that is a solution
that fits your requirement + constraint, but
I am sure you also don't want to hear this
possibility :-)

-marcel

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

#45502

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-02-13 11:27 +0000
Message-ID	<2016Feb13.122718@mips.complang.tuwien.ac.at>
In reply to	#45496

minforth@arcor.de writes:
>This leads me to the following silly question:
>
>Is there a clever algorithm that converts locals syntax to stack juggling for Forths that have no locals implemented?

One possible answer to that question was given by Glass [glass83]: He
had a locals-like syntax for naming stack elements, but the elements
were kept on the data stack, and mentioning one by name resulted in
compiling <n> PICK (or, for changing the value, <n> STICK).  IIRC his
compiler knew the stack effect of words and kept track of the stack
depth statically.

@InCollection{glass83,
  author = 	"Harvey Glass",
  title = 	"Towards a More Writable {Forth} Syntax",
  crossref =	"ouverson86",
  chapter = 	"21",
  pages = 	"169--181",
  note = 	"Reprinted from {\em Proceedings of the 1983 Rochester
		 Forth Applications Conference}"
}

@Book{ouverson86,
  booktitle = 	 {Dr.\ Dobb's Toolbook of Forth},
  publisher = 	 {M\&T Books},
  year = 	 {1986},
  editor =	 {Marlin Ouverson},
  address =	 {Redwood City, CA 94063}
}

Another possible answer is the stack manipulation optimizer I posted
here a few years ago:
<http://www.complang.tuwien.ac.at/forth/stack-opt>.  I guess one could
extend this to deal with straight-line code containing other words
than stack manipulation, but the simple exhaustive search is limited
to just a few words.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45503

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-02-13 12:33 +0000
Message-ID	<2016Feb13.133301@mips.complang.tuwien.ac.at>
In reply to	#45502

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Another possible answer is the stack manipulation optimizer I posted
>here a few years ago:
><http://www.complang.tuwien.ac.at/forth/stack-opt>.  I guess one could
>extend this to deal with straight-line code containing other words
>than stack manipulation, but the simple exhaustive search is limited
>to just a few words.

I have now extended the old version with rules for '+' to show that it
is not limited to stack manipulation words.  Drawback: The more words
you add, the slower the search becomes.  + also demonstrates that we
can specify commutativity and make use of that in the optimization.

A simple case:

?- find([swap,+],[a,b,c,d],[],X,[]), findbest(L,[a,b,c,d],[],X,[]).
X = [b+a, c, d],
L = [+] .

I queried Prolog to give me all sequences L equivalent to [swap,+],
starting with the shortest one(s).  I provide a data stack with four
elements (with the leftmost element being the TOS) and a return stack
with none at the start, so the system can work.  As the first result,
Prolog found L=[+], so it recognized that SWAP + is equivalent to +
(based on the stack effect of SWAP and the two stack effects of +).

A more complex case:

?- find([dup,'>r',+,'r>'],[a,b,c,d],[],X,[]), findbest(L,[a,b,c,d],[],X,[]).
X = [a, a+b, c, d],
L = [tuck, +, swap] .

Here I find that a shorter way to write DUP >R + R> is TUCK + SWAP.

For a better answer to the original poster, I also added a way to
specify that one is reading a local, and a predicate for directly
querying for the equivalence we want.

?- loc_stack([l(b),l(d),+,l(a),l(c),+],L,[a,b,c,d],X).
L = [rot, +, '>r', +, 'r>'],
X = [c+a, d+b] .

Here I asked the system to give me a locals-less sequence L that is
equivalent to the sequence with locals "b d + a c +", and for L the
starting stack is "d c b a", while for the locals sequence it is
empty; X is the stack contents of both sequences at the end.

Here's the enhanced program:

%eff(Word,Data_Stack_in, Return_Stack_in, Data_Stack_out, Return_Stack_out).
eff(swap,[A,B|D],R,[B,A|D],R).
eff(dup,[A|D],R,[A,A|D],R).
eff(drop,[_|D],R,D,R).
eff('>r',[A|D],R,D,[A|R]).
eff('r>',D,[A|R],[A|D],R).
eff('r@',D,[A|R],[A|D],[A|R]).
eff(rot,[A,B,C|D],R,[C,A,B|D],R).
eff(over,[A,B|D],R,[B,A,B|D],R).
eff('2dup',[A,B|D],R,[A,B,A,B|D],R).
eff(nip,[A,_|D],R,[A|D],R).
eff(tuck,[A,B|D],R,[A,B,A|D],R).
eff(+,[A,B|D],R,[A+B|D],R).
eff(+,[A,B|D],R,[B+A|D],R).

%delay find(nonvar,any,any,any,any).
find([],D,R,D,R).
find([Word|Words],Din,Rin,Dout,Rout):-
	eff(Word,Din,Rin,D1,R1),
	find(Words,D1,R1,Dout,Rout).

findloc([],D,R,D,R).
findloc([l(V)|Words],Din,Rin,Dout,Rout):-
	findloc(Words,[V|Din],Rin,Dout,Rout).
findloc([Word|Words],Din,Rin,Dout,Rout):-
	eff(Word,Din,Rin,D1,R1),
	findloc(Words,D1,R1,Dout,Rout).

findbest(L,Din,Rin,Dout,Rout):-
	genlist(L),
	find(L,Din,Rin,Dout,Rout).

loc_stack(L1,L2,Din,Dout):-
	findloc(L1,[],[],Dout,[]),
	findbest(L2,Din,[],Dout,[]).

genlist([]).
genlist([_|T]):- genlist(T).

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45539

From	minforth@arcor.de
Date	2016-02-15 01:05 -0800
Message-ID	<d04427fe-575e-417f-896c-c71c1c9985de@googlegroups.com>
In reply to	#45503

Many thanks, Anton, for your postings.

I knew of the "stack frame solution" by picking named data stack elements.

But using CLP or Prolog as "juggling minimizer" was new to me. It reminds me of times long ago where I used Turbo Prolog as optimizing Forth Compiler (it could compete with Tom Zimmer's TCOM then). That was big fun and Prolog opened new vistas of thinking as a programmer.

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

#45529

From	dunno <dunno@dunno.dunno>
Date	2016-02-14 19:34 +0000
Message-ID	<892536749.477132066.893404.dunno-dunno.dunno@news.mixmin.net>
In reply to	#45496

<minforth@arcor.de> wrote:
> This leads me to the following silly question:
> 
> Is there a clever algorithm that converts locals syntax to stack juggling
> for Forths that have no locals implemented?

Honestly, I can't think of the case where locals are so badly needed that
they have to be somehow emulated.

-- 
dunno

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

#45505

From	Julian Fondren <julian.fondren@gmail.com>
Date	2016-02-13 06:43 -0800
Message-ID	<55c0a3a4-1ea0-4f9c-ab47-df8dc7fb0a88@googlegroups.com>
In reply to	#45489

On Friday, February 12, 2016 at 3:57:08 PM UTC-6, lahe...@gmail.com wrote:
> When I'm reading forth code, I have to work hard to remember the contents of the stack. Especially when a word is more than a few subwords long, or contains words whose stack effects I have to go and look up, I am likely to forget what the stack looks like at the point I was just at. So I have to backtrack to a previous known stack state, and recover the context by reading word by word.

In order to understand what code is doing you have to keep track of
state affected by the code. Even in FP, if you have e.g. a list
that's threaded through three functions, you have to keep track of
transformations on that list to understand what the result will be.
From this it might be argued that Forth doesn't require that more be
kept in mind than does in other languages, and so that it shouldn't
be any harder to read.

But if you take another language and write it in a Forth-like
manner, you can see that this removes visual cues that would
normally be present, and which would be present in Forth if you
emphasized local variables. This is most obvious when you're
calling a lot of functions: one style requires that you remember
precisely how many arguments the functions take and how many they
return; the other style makes this explicit. But even if you just
take arguments and consume them, in one style it's always clear
which argument you're working with, and in the other that's only
known if you keep track of the arguments across the function.

The second case, in Perl:

sub set_socket_address {
my ($sockaddr, $port, $ip) = @_;
$sockaddr->[SIN_FAMILY] = PF_INET;
$sockaddr->[SIN_FAMILY+1] = 0;
$sockaddr->[SIN_PORT] = $port >> 8;
$sockaddr->[SIN_PORT+1] = $port & 0xFF;
splice(@$sockaddr, SIN_ADDR, 0,
map { hex $_ } split /(..)/, $ip);
}

vs.

sub set_socket_address { # ( ip port sockaddr -- )
for (shift) {
$_->[SIN_FAMILY] = PF_INET;
$_->[SIN_FAMILY+1] = 0;
$_->[SIN_PORT] = $_[0] >> 8;
$_->[SIN_PORT+1] = shift & 0xFF;
splice(@$_, SIN_ADDR, 4,
map { hex $_ } split /(..)/, shift);
}
}

shift appears three times. First meaning the sockaddr, and then the
port, and then the ip. $_[0] means the port where it appears, but
would mean the sockaddr or the ip if it appeared elsewhere. $_
means the sockaddr throughout, except in { hex $_ } where it refers
to in turn to each octet of the IP.

This is like using a bunch of pronouns, instead of nouns. It's
just objectively more to keep track of.

The original Forth:

: socket-address! ( ip port a -- )
>o PF_INET sin_family C! 0 sin_family' C!
DUP 8 RSHIFT sin_port C! 255 AND sin_port' C!
( ip ) sin_addr ! \ works in 64 and 32 bit both
o> ;

So to an extent, keeping track of the stack is a skill to be learned
and you'll get better at it. You're a human and already speak some
human language so you already some facility here and may just need
to get used to applying it to code. OTOH, you're a human and your
language doesn't have an infinite number of pronouns: it's also
important to code in a way that doesn't require that you keep track
of silly amounts of data on the stack. Which is a *second* skill
that Forth requires of you that other languages don't as much.

If you'd like help with that, post some Forth that you're having
trouble following. Someone may be able to show you how it could be
more clearly written.

Again, if you're calling a bunch of functions, in Forth you have to
know the stack effects of these words whereas in another language
that would be explicit. I think the burden of "knowing what words
do" is one that I would be happy to bear in other languages, but
there is sort of a maintenance-programmer argument to make here,
that it's desirable to be able to usefully modify programs while
knowing as little as possible about them, and Forth will tend to
require that more be known.

In the end I think that Forth's burdens are pretty light, and that
they're a package deal with conveniences. You can have some very
nice code which can be easy to follow and understand because the
trivial details are suppressed.

For example, I'm responsible for some code that physically migrates
MySQL databases between filesystem partitions, and that does so
without shutting MySQL off. It was *extremely* important to me that
the external logic of this code, that its effect on the database and
the filesystem, was as clear as possible. Mainly because I myself
had a hard time following those operations. If they had a flaw, I
wanted anyone looking at the operations to be able to easily find
it.

There are two general ways to do what I wanted to do: I could've
written a single giant function that used very simple operations and
logic, so that all someone would have to do is read this one
function - they wouldn't need to know what the rest of the program
did, or what any separate library did, or even much about the
programming language. This might be preferable if you need a
programmer to certify that your entire program really does what it
says it does.

What I did instead was write a very tiny function that read like a
recipe, that was written as if in a DSL for operations on MySQL
datadirs, and then I wrote other code to support that. This is
preferable if you want people who aren't necessarily programmers to
be able to certify that "what your code says it does" is sensible.

And the second case is the ideal of readable Forth, like the classic
washing machine example. Someone who knows about washing machines
can look at the final words and say, yep, that's what I want the
washing machine to do. They don't need to understand the initial
words with the magic numbers for I/O ports and whatnot.

Anyway, as rules:

1. Use stack comments when you define words. Always. If some
heretic tells you that you can replace stack comments with some
discipline about short definitions, burn him at the stake.

In some special cases you can use a single stack comment for
some related words:

( 'arg' -- f )
: all no-arg true ;
: bounce no-arg "F From: <>" ~header ;
: to "To:" header-has? ;
: from "From:" header-has? ;
: header ~header ;
: body ~body ;

'blah', with single quotes, is my own notation for a ( c-addr u )
pair. A popular notation like this is d1 which refers to a double
number and two actual cells on the stack. As a subrule: where it
helps, adapt your stack notation to your program. You can say 'ip'
instead of 'c c c c' if you're always holding four bytes on the
stack for an IP.

2. Prefer consuming all of your arguments and prefer always doing
the same thing to the stack. But go ahead and do otherwise in the
special case when it helps.

3. Use data structures and memory. When writing Forth, just don't
worry about your 'global variables' being evil. Forth removes all
but threaded reentrancy as a real concern with them.

4. Use 'phrasing', whitespace within definitions to separate code
into logical groups of words, and vertically align similar code.
This might not seem like it'd help you follow the stack, but it
tends to help enormously with that.

5. A good soft limit is three items on the data stack and one item
on the return stack. You can *have* more than that, even within a
definition, but at no point should you be reaching further into
either stack. An 'item' for this purpose can consist of more than
one cell. Words like THIRD FOURTH and FIFTH can be useful, but just
forget about ROLL and PICK

6. Use good names. Don't worry about universally unique names, or
worry much about redefining existing words. Forth's dictionary
means that anything using the existing words is still happily using
them, and doesn't care about your higher level code. If it comes to
it you can use vocabularies to manage the mess.

If you place burdens on naming then you're placing burdens on the
hardest part of factoring and good factoring lends itself to easy
stack management.

7. If you're getting frustrated, go ahead and use local variables.

-- Julian

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

#45540

From	minforth@arcor.de
Date	2016-02-15 01:22 -0800
Message-ID	<ac22d4d5-6d55-462e-b829-0fc91920c0c8@googlegroups.com>
In reply to	#45505

I agree with you Julian.
Coding style and discipline goes with code readability and program quality.

But today more compiler intelligence is expected to release the programmer from some burdensome tasks (like remembering stack positions) to make better usage of human intelligence and productivity.

I know it sounds like blabla, but for another example: I always wondered why DUP should not be intelligent enough that it is really a FDUP or 2DUP or such. Operator overloading is no witch work after all.

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

#45541

From	dunno <dunno@dunno.dunno>
Date	2016-02-15 09:48 +0000
Message-ID	<1091747284.477222105.293024.dunno-dunno.dunno@news.mixmin.net>
In reply to	#45540

<minforth@arcor.de> wrote:
> I know it sounds like blabla, but for another example: I always wondered
> why DUP should not be intelligent enough that it is really a FDUP or 2DUP
> or such. Operator overloading is no witch work after all.

Because integers and floats in most cases are kept in different stacks.
Computer cannot read your mind to find out which top of stack element have
to be duplicated.

-- 
dunno

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

#45542

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-02-15 09:53 +0000
Message-ID	<2016Feb15.105330@mips.complang.tuwien.ac.at>
In reply to	#45540

minforth@arcor.de writes:
>I agree with you Julian.
>Coding style and discipline goes with code readability and program quality.
>
>But today more compiler intelligence is expected to release the programmer from some burdensome tasks (like remembering stack positions) to make better usage of human intelligence and productivity.

And today we have compilers that support locals.

>I know it sounds like blabla, but for another example: I always wondered why DUP should not be intelligent enough that it is really a FDUP or 2DUP or such. Operator overloading is no witch work after all.

1 2e 3 dup

Should the DUP be (single-cell) DUP, FDUP, or 2DUP?

Given the problems I have experienced with operator-overloaded
languages, I prefer the Forth approach.  In particular, the
availability of operator overloading in C has led to the C integer
type zoo, and I have seen many more portability bugs in C than in
Forth where integer sizes were involved.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45544

From	Albert van der Horst <albert@spenarnc.xs4all.nl>
Date	2016-02-15 11:26 +0000
Message-ID	<56c1b601$0$23760$e4fe514c@news.xs4all.nl>
In reply to	#45542

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>minforth@arcor.de writes:
>>I agree with you Julian.
>>Coding style and discipline goes with code readability and program quality.
>>
>>But today more compiler intelligence is expected to release the programmer from some burdensome tasks (like remembering stack positions) to make better usage of human intelligence and productivity.

>And today we have compilers that support locals.

>>I know it sounds like blabla, but for another example: I always wondered why DUP should not be intelligent enough that it is really a FDUP or 2DUP or such. Operator overloading is no witch work after all.

>1 2e 3 dup

>Should the DUP be (single-cell) DUP, FDUP, or 2DUP?

>Given the problems I have experienced with operator-overloaded
>languages, I prefer the Forth approach.  In particular, the
>availability of operator overloading in C has led to the C integer
>type zoo, and I have seen many more portability bugs in C than in
>Forth where integer sizes were involved.

The short answer is, operator overloading goes with typed languages.
Forth is untyped.

>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#45547

From	minforth@arcor.de
Date	2016-02-15 04:53 -0800
Message-ID	<8906a89c-0486-4f44-af99-589848940a6b@googlegroups.com>
In reply to	#45544

Am Montag, 15. Februar 2016 12:27:42 UTC+1 schrieb Albert van der Horst:
> The short answer is, operator overloading goes with typed languages.
> Forth is untyped.

At a first glance, and mostly: Yes.

But it recognizes (some) types: 1 2. 3.0e <- 3 different types recognized

Why not make better usage of this information later?

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

#45549

From	dunno <dunno@dunno.dunno>
Date	2016-02-15 17:06 +0000
Message-ID	<1286489993.477247715.408086.dunno-dunno.dunno@news.mixmin.net>
In reply to	#45547

<minforth@arcor.de> wrote:
> Am Montag, 15. Februar 2016 12:27:42 UTC+1 schrieb Albert van der Horst:
>> The short answer is, operator overloading goes with typed languages.
>> Forth is untyped.
> 
> At a first glance, and mostly: Yes.
> 
> But it recognizes (some) types: 1 2. 3.0e <- 3 different types recognized
> 
> Why not make better usage of this information later? 

Can you please clarify how it could be done in Forth implementation with
two different stacks for integers and floats?

I would like to add that there are very legitimate reasons to keep numbers
on two different stacks. Some processors (namely, x86 and x86-64) actually
do have two different stacks, including FP stack, and authors of Forth
implementations are able to use it directly instead of keeping floats in
memory and moving them to FP stack when needed.

-- 
dunno

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

#45579

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-02-16 14:57 +0000
Message-ID	<2016Feb16.155705@mips.complang.tuwien.ac.at>
In reply to	#45549

dunno <dunno@dunno.dunno> writes:
>I would like to add that there are very legitimate reasons to keep numbers
>on two different stacks. Some processors (namely, x86 and x86-64) actually
>do have two different stacks, including FP stack, and authors of Forth
>implementations are able to use it directly instead of keeping floats in
>memory and moving them to FP stack when needed.

Actually with typical Forth idiomatics and a sufficiently
sophisticated compiler, it is possible to combine various Forth stacks
into one in the implementation, or also split a combined stack into
several for a good part of the code.

But even in such an environment the FP stack is a good idea, for a
similar reason that we have separate FP registers in hardware: there
are relatively few integer operations that make sense on FP values and
vice versa.  In hardware the separate FP registers allow keeping the
integer data close to the integer units and the FP data close to the
FP units, and they also mean that the port requirements of integer and
FP units do not add up in the register files.  In Forth the separate
stacks allow us to avoid stack shuffling when dealing with FP values
(in addition to making it easier for not-sufficiently-sophisticated
compilers to make good use of FP registers or the 80387 FP stack).

There have also been ideas like a separate stack for addresses, but
the overlap of instructions between integers and addresses is so large
that this does not make that much sense; likewise, instruction sets
with general-purpose registers won out over instruction sets like the
68000 with separate address and data registers.

However, as a counterexample to my argument, the Intel SIMD registers
(XMM, YMM etc.)  may contain vectors of integers as well as vectors of
FP values, and there are instructions for dealing with both kinds of
data.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45574

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-02-16 14:14 +0000
Message-ID	<2016Feb16.151440@mips.complang.tuwien.ac.at>
In reply to	#45544

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>Forth is untyped.

The term "untyped" is not defined very well and is usually misleading.
Forth has types, but neither the compiler nor the run-time system
perform type checking.  Yet the sequence "c@ @" is considered a type
error by Forth programmers (unless it is code specific to a platform
with very specific properties).

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45543

From	Ron Aaron <rambamist@gmail.com>
Date	2016-02-15 12:31 +0200
Message-ID	<n9s99g$8v5$1@dont-email.me>
In reply to	#45540


On 02/15/2016 11:22, minforth@arcor.de wrote:

> I know it sounds like blabla, but for another example: I always wondered why DUP should not be intelligent enough that it is really a FDUP or 2DUP or such. Operator overloading is no witch work after all.

Because traditional Forths usually have different sizes for different
items (cell vs double-cell) or use different stacks (integer vs float).

I agree with you, which is why 8th uses the same stack for any kind of
item -- you just use "dup" no matter what kind of item it is.

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

#45609

From	Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date	2016-02-18 22:53 +0000
Message-ID	<20160218225338.6d50813f@t500>
In reply to	#45540

On Mon, 15 Feb 2016 01:22:54 -0800 (PST)
minforth@arcor.de wrote:

... 

> I know it sounds like blabla, but for another example: I
> always wondered why DUP should not be intelligent enough that
> it is really a FDUP or 2DUP or such. Operator overloading is
> no witch work after all.

StrongForth from Stephan Becher provided this, early versions
were 16b DOS, later one(s?) (v1.1) is ANS Forth. 

His account here is dead:
  http://home.vrweb.de/~stephan.becher/forth.

Many c.l.f refs from ~8 yrs ago, like this:
"Version 1.4 of StrongForth is now available for download at
http://home.vrweb.de/~stephan.becher/forth"

If you cannot find Dr Becher, I have 

.../ANSforth-hosted/forth.zip 96.1kB  StrongForth 1.1

Data Types are named in stack comments, the manual says:

In the previous section, we have introduced four data types:
UNSIGNED, SIGNED, CHARACTER, and FLAG. Actually, StrongForth
knows a lot more data types, and it is even possible to define
new, application-specific data types.

Jan Coomvs
--

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

#45506

From	Doug Hoffman <glidedog@gmail.com>
Date	2016-02-13 10:51 -0500
Message-ID	<56bf5101$0$293$14726298@news.sunsite.dk>
In reply to	#45489

On 2/12/16 4:57 PM, laheadle@gmail.com wrote:
> When I'm reading forth code, I have to work hard to remember the
> contents of the stack. Especially when a word is more than a few
> subwords long, or contains words whose stack effects I have to go and
> look up, I am likely to forget what the stack looks like at the point
> I was just at. So I have to backtrack to a previous known stack
> state, and recover the context by reading word by word.

It helps to have a Forth that allows *instant* word lookup with stack
effects. I use MFonVFX. A right-click on a word in the integrated editor
does exactly that(and more actually). There are other quality Forths
that do essentially the same. Get one.

-Doug

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

#45512

From	"HAA" <someone@microsoft.com>
Date	2016-02-14 10:18 +1100
Message-ID	<n9odjr$7rl$1@gioia.aioe.org>
In reply to	#45489

laheadle@gmail.com wrote:
> ...
> One thing I do is mentally "say" the contents of the stack after every word: "a b c...b
> c a...c a..." etc. This seems to help my memory.

There's also nothing stopping you from recording these partial stack comments
in your code as you go.  It's useful when code is a bit long or tricky and it's great
documentation for anyone that has to read it later.

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

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

csiph-web

How do you remember the stack?

Contents

#45507

#45500

#45501

#45502

#45503

#45539

#45529

#45505

#45540

#45541

#45542

#45544

#45547

#45549

#45579

#45574

#45543

#45609

#45506

#45512