Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #36318 > unrolled thread
| Started by | Aliaksei Chapyzhenka <alex.drom@gmail.com> |
|---|---|
| First post | 2015-02-05 20:01 -0800 |
| Last post | 2015-02-08 10:51 +0000 |
| Articles | 20 on this page of 111 — 18 participants |
Back to article view | Back to comp.lang.forth
Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-05 20:01 -0800
Re: Static Single Assignment form to Stack allocation Paul Rubin <no.email@nospam.invalid> - 2015-02-05 21:00 -0800
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-06 02:15 -0500
Re: Static Single Assignment form to Stack allocation Paul Rubin <no.email@nospam.invalid> - 2015-02-06 12:07 -0800
Re: Static Single Assignment form to Stack allocation Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-02-08 22:38 +0000
Re: Static Single Assignment form to Stack allocation Paul Rubin <no.email@nospam.invalid> - 2015-02-08 14:55 -0800
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-08 19:59 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-06 13:15 +0000
Re: Static Single Assignment form to Stack allocation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-06 13:22 +0000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-06 11:16 -0800
Re: Static Single Assignment form to Stack allocation Paul Rubin <no.email@nospam.invalid> - 2015-02-06 12:05 -0800
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-06 16:44 -0800
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-06 23:41 -0500
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-06 23:41 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-07 19:22 +0000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-07 13:09 -0800
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-07 11:25 -1000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-07 14:09 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-07 22:32 +0000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-07 14:51 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 00:04 +0000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-07 17:03 -0800
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-07 21:04 -0500
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-07 21:10 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 10:57 +0000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-07 21:05 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-07 22:24 +0000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-07 11:21 -1000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-07 20:11 -0500
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-07 15:35 -1000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-07 16:52 -1000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-08 10:21 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 20:09 +0000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-08 17:15 -1000
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-09 12:00 +0000
Re: Static Single Assignment form to Stack allocation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-09 13:05 +0000
Re: Static Single Assignment form to Stack allocation "HAA" <someone@microsoft.com> - 2015-02-10 16:01 +1100
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-09 02:35 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-09 12:03 +0000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-08 10:13 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 20:21 +0000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-09 22:49 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 12:12 +0000
Re: Static Single Assignment form to Stack allocation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-10 12:54 +0000
Re: Static Single Assignment form to Stack allocation Mark Wills <markwills1970@gmail.com> - 2015-02-10 06:30 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 14:53 +0000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-10 08:20 -1000
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 14:33 +0000
Re: Static Single Assignment form to Stack allocation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-10 19:09 +0000
Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-10 14:29 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 15:49 +0000
Re: Control-flow stack (was: Static Single Assignment ...) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-10 17:56 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 20:53 +0000
Re: Control-flow stack "Elizabeth D. Rather" <erather@forth.com> - 2015-02-10 13:08 -1000
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-11 03:15 +0100
Re: Control-flow stack hughaguilar96@gmail.com - 2015-02-10 18:47 -0800
Re: Control-flow stack Unknown <dog@gmail.com> - 2015-02-17 07:13 +0000
Re: Control-flow stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-11 17:59 +0000
Re: Control-flow stack (was: Static Single Assignment ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-02-11 01:30 -0800
Re: Control-flow stack (was: Static Single Assignment ...) "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-10 18:43 -0500
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-11 17:46 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 22:39 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 22:42 +0000
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-12 09:52 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-12 10:28 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-11 20:23 -0800
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-12 07:21 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-12 18:33 -0800
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-13 04:46 +0100
Re: Control-flow stack "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-13 06:48 -0500
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-13 13:40 +0100
Re: Control-flow stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-13 15:49 +0000
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-14 03:47 +0100
Re: Control-flow stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-13 16:09 +0000
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-13 15:20 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-13 21:31 -0800
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-14 03:47 +0100
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-14 19:22 -0800
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-15 11:09 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-15 16:57 -0800
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-16 14:41 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-16 18:43 -0800
Re: Control-flow stack Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-02-10 22:04 +0000
Re: Control-flow stack Harold <hzrabbie@gmail.com> - 2015-02-10 16:58 -0800
Re: Control-flow stack Bernd Paysan <bernd.paysan@gmx.de> - 2015-02-11 02:51 +0100
Re: Control-flow stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-11 11:34 +0000
Re: Control-flow stack Harold <hzrabbie@gmail.com> - 2015-02-11 08:17 -0800
Re: Control-flow stack "Elizabeth D. Rather" <erather@forth.com> - 2015-02-10 16:37 -1000
Re: Control-flow stack hughaguilar96@gmail.com - 2015-02-10 18:57 -0800
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-10 18:44 -0500
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-10 14:49 -1000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-10 18:16 -0800
Re: Static Single Assignment form to Stack allocation Mark Wills <markwills1970@gmail.com> - 2015-02-11 00:35 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 09:35 +0000
Re: Static Single Assignment form to Stack allocation Mark Wills <markwills1970@gmail.com> - 2015-02-11 03:06 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 14:27 +0000
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 14:40 +0000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-12 20:02 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-13 11:42 +0000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-13 07:44 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-13 14:20 +0000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-13 10:32 -1000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-29 16:27 -0400
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-03-29 22:46 +0100
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-03-29 15:24 -1000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-03-30 04:44 -0700
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-03-30 15:33 +0100
Re: Static Single Assignment form to Stack allocation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-11 18:03 +0000
Re: Static Single Assignment form to Stack allocation Bernd Paysan <bernd.paysan@gmx.de> - 2015-02-12 00:16 +0100
Re: Static Single Assignment form to Stack allocation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-12 07:08 +0000
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 10:51 +0000
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-16 14:41 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <2015Feb16.154101@mips.complang.tuwien.ac.at> |
| In reply to | #36589 |
hughaguilar96@gmail.com writes:
>Well, in all OOP systems there is a stack of objects, with THIS being the t=
>op element --- so you get a mechanism for saving and restoring --- it is st=
>ill essentially a global variable though.
In some OO systems the saving and restoring mechanism is explicit
(e.g., Bernd Paysan's systems), in others it is implicit on method
entry (e.g., objects.fs). Even in the former case I find the view
that it is a global variable quite unusual; it's the same as we get
with R@ (THIS or O), >R (>O), and R> DROP (O>), and nobody has claimed
that the top of the return sack is a global variable.
>As I said before, this is a work-around for the problem in ANS-Forth that t=
>he data-stack can't be used for data during compile-time of colon words.
It's a workaround for the problem that you want to access the
>I had never heard of GRAY before this discussion. I can't comment further o=
>n it without examining it --- can I download it somewhere?
>
>I'm writing an assembler right now, so your GRAY might be useful --- it is =
>an assembler, right?
It's a parser generator, and you can find it on
<http://www.complang.tuwien.ac.at/forth/gray.zip>
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-16 18:43 -0800 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <09be8378-769e-4b4d-b43a-2369fe79c0ec@googlegroups.com> |
| In reply to | #36606 |
On Monday, February 16, 2015 at 8:00:32 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >Well, in all OOP systems there is a stack of objects, with THIS being the t=
> >op element --- so you get a mechanism for saving and restoring --- it is st=
> >ill essentially a global variable though.
>
> In some OO systems the saving and restoring mechanism is explicit
> (e.g., Bernd Paysan's systems), in others it is implicit on method
> entry (e.g., objects.fs). Even in the former case I find the view
> that it is a global variable quite unusual; it's the same as we get
> with R@ (THIS or O), >R (>O), and R> DROP (O>), and nobody has claimed
> that the top of the return sack is a global variable.
Of course the return-stack is a global data-structure.
This is why it is a problem that both >R and DO use the return-stack, so you get a clash when they are used together in the same colon word --- also, colon words use the return-stack for return-addresses, so this use clashes with both >R and DO also, causing R@ and I to not be accessible in sub-functions.
All of these could have been separate stacks. The reason why one stack is used for three unrelated purposes, is because on the PDP-11 there weren't enough registers to have three separate stack-pointers, so Charles Moore just combined everything together on one stack. As a general rule, if you are going to have a global data-structure, it should be used for only one thing --- not multiple unrelated purposes.
Even if you accept the limitations of the PDP-11 and assume that you have only one register (the return-stack pointer) available, PolyForth was still badly designed. >R was a big mistake. If Charles Moore had implemented local variables instead (and all local variables are allocated on the return-stack at the beginning of the colon word), then he still could have used the return-stack for DO loops without any clash (the offset to the local variables would be adjusted inside of the DO loops). >R is a mistake --- >R effectively allocates one local variable (called R@ every time) on the return-stack, but >R can be done at any time throughout the colon word (including inside of BEGIN loops), so this clashes with any other use of the return-stack such as DO loops --- local variables work without any clash if you allocate all of them in one swoop at the beginning of the function. The sad fact is that not everything Charles Moore did was pure genius --- >R was a gross mistake that should have been abandoned decades ago. Forth-83 would have been a good time to get rid of >R --- Forth-83 was incompatible with Forth-79 anyway, so if Forth-83 had local variables but did not have >R, then this would have just been another incompatibility that the programmers would have needed to deal with --- a new standard has to fix the problems in the old standard, and the programmers just have to man up and convert their legacy code to the new standard. This is like taking medicine that tastes bad, but you feel better afterward so it is worthwhile --- and the Forth-200x committee members who refuse to abandon the gross mistakes of ANS-Forth and make Forth-200x incompatible, are like little kids who refuse to take their medicine and consequently remain sick forever.
The only feature that >R provides that local variables do not provide, is the ability to work with variable numbers of data. An example is NON-ZEROS in the novice package:
: non-zeros ( 0 numbers... -- 0 numbers... count )
0 \ -- count
0 >r begin over while swap >r 1+ repeat nip
0 swap begin r> ?dup while swap repeat ;
If >R were discarded, this couldn't be done with local variables. This is actually quite rare however, so this isn't a big loss --- variable numbers of data could be put in a list (see LIST.4TH in the novice package) rather than held on the data-stack, and the code would actually be a lot more readable anyway.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-02-10 22:04 +0000 |
| Subject | Re: Control-flow stack |
| Message-ID | <mbdv8i$o3v$1@dont-email.me> |
| In reply to | #36431 |
On 10/02/2015 14:29, Anton Ertl wrote: > albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >> In article <mbcshk$nri$1@dont-email.me>, >> Alex McDonald <blog@rivadpm.com> wrote: >>> Where this wouldn't work is >>> >>> : foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >>> .. ; >>> >>> Here the control flow, if on the data stack, has pushed down the literals >>> and we can't get at them. Are you claiming this is idiomatic, with use of >>> LITERAL inside a control flow where the literal value is put on the stack >>> before it? >>> >> >> If Hugh isn't, I am. And it is a pitfall because one needs to read the >> standard very carefully to realize that : might leave something >> on the control stack. > > You mean the data stack, and the case you are thinking of is not the > one Alex McDonald presented as example. What you are thinking of is > simething like > > buf-size maxbuffer - : foo literal + ; > > Here Forth-94 says: > > |6.1.0450 : colon CORE\ > | ( C: "<spaces>name" -- colon-sys ) > > 2.2.2 "Stack notation" explains that C: stands for the control-flow > stack, and 3.2.3.2 "Control-flow stack" explains that the control-flow > stack may be implemented using the data stack. > > I don't think this needs more careful reading than other aspects of > the standard. > > It seems to me that using the data stack as control-flow stack is > common practice (are there any exceptions?). Yes, my system has a separate stack, used for control-flow and information about locals during compilation. Like Hugh I have found use of the data stack for control-flow an irritation in the past but live with the restriction. Anyway there are workarounds using DEPTH with PICK or ROLL, alternatively using Michael Gassanenko's PASS : pass >r ' execute r> ; immediate 123 pass : foo literal ; foo . s" Hello" pass pass : bar sliteral ; bar type > Tightening the standard > to disallow a separate control-flow stack would not give progammers a > lot of additional freedom, because all the control-flow stack items > are opaque and the number of cells they contain is not standardized; > but it would have the following effects: > > * No need to document the possibility of a separate control-flow > stack. The standard becomes easier to understand. > > * Programmers could use DEPTH to find out the size of an individual > control-flow stack item, and then copy it, store it to memory, or > otherwise manipulate it. > This is probably ok for many compilers, > but other compilers might have been written with the assumption that > only the standard control-flow stack manipulation words are used for > dealing with control-flow stack items, and would not work with the > programmer-written ones. Are there such compilers? Yes mine. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Harold <hzrabbie@gmail.com> |
|---|---|
| Date | 2015-02-10 16:58 -0800 |
| Subject | Re: Control-flow stack |
| Message-ID | <f5f1fb0e-e0b1-47f7-96db-ea52e0ceb0a0@googlegroups.com> |
| In reply to | #36441 |
On Tuesday, February 10, 2015 at 2:04:42 PM UTC-8, Gerry wrote: > On 10/02/2015 14:29, Anton Ertl wrote: > > albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > >> In article <mbcshk$nri$1@dont-email.me>, > >> Alex McDonald <blog@rivadpm.com> wrote: > >>> Where this wouldn't work is > >>> > >>> : foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then > >>> .. ; > >>> > >>> Here the control flow, if on the data stack, has pushed down the literals > >>> and we can't get at them. Are you claiming this is idiomatic, with use of > >>> LITERAL inside a control flow where the literal value is put on the stack > >>> before it? > >>> > >> > >> If Hugh isn't, I am. And it is a pitfall because one needs to read the > >> standard very carefully to realize that : might leave something > >> on the control stack. > > > > You mean the data stack, and the case you are thinking of is not the > > one Alex McDonald presented as example. What you are thinking of is > > simething like > > > > buf-size maxbuffer - : foo literal + ; > > > > Here Forth-94 says: > > > > |6.1.0450 : colon CORE\ > > | ( C: "<spaces>name" -- colon-sys ) > > > > 2.2.2 "Stack notation" explains that C: stands for the control-flow > > stack, and 3.2.3.2 "Control-flow stack" explains that the control-flow > > stack may be implemented using the data stack. > > > > I don't think this needs more careful reading than other aspects of > > the standard. > > > > It seems to me that using the data stack as control-flow stack is > > common practice (are there any exceptions?). > > Yes, my system has a separate stack, used for control-flow and > information about locals during compilation. Like Hugh I have found use > of the data stack for control-flow an irritation in the past but live > with the restriction. Anyway there are workarounds using DEPTH with PICK > or ROLL, alternatively using Michael Gassanenko's PASS > > : pass >r ' execute r> ; immediate > 123 pass : foo literal ; foo . > s" Hello" pass pass : bar sliteral ; bar type > > > Tightening the standard > > to disallow a separate control-flow stack would not give progammers a > > lot of additional freedom, because all the control-flow stack items > > are opaque and the number of cells they contain is not standardized; > > but it would have the following effects: > > > > * No need to document the possibility of a separate control-flow > > stack. The standard becomes easier to understand. > > > > * Programmers could use DEPTH to find out the size of an individual > > control-flow stack item, and then copy it, store it to memory, or > > otherwise manipulate it. > > > > This is probably ok for many compilers, > > but other compilers might have been written with the assumption that > > only the standard control-flow stack manipulation words are used for > > dealing with control-flow stack items, and would not work with the > > programmer-written ones. Are there such compilers? > > Yes mine. > > -- > Gerry I think there has to be in any case a separate control-flow stack to handle LEAVE correctly. LEAVE has to leave just the innermost enclosing DO .. LOOP. It can be invoked inside of arbitrary control flow structures like IF .. THEN, so it can't use the main control-flow stack. In a memory-constrained environment, it's slightly annoying to have to allocate a third stack which is going to be rarely used.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-02-11 02:51 +0100 |
| Subject | Re: Control-flow stack |
| Message-ID | <mbecii$8gr$2@dont-email.me> |
| In reply to | #36451 |
Harold wrote: > I think there has to be in any case a separate control-flow stack to > handle LEAVE correctly. LEAVE has to leave just the innermost enclosing > DO .. LOOP. It can be invoked inside of arbitrary control flow structures > like IF .. THEN, so it can't use the main control-flow stack. > > In a memory-constrained environment, it's slightly annoying to have to > allocate a third stack which is going to be rarely used. You can store the necessary information for chaining all LEAVEs within one DO..LOOP in the forward branches you have compiled. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/ net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-02-11 11:34 +0000 |
| Subject | Re: Control-flow stack |
| Message-ID | <54db3e28$0$14929$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #36453 |
In article <mbecii$8gr$2@dont-email.me>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Harold wrote: >> I think there has to be in any case a separate control-flow stack to >> handle LEAVE correctly. LEAVE has to leave just the innermost enclosing >> DO .. LOOP. It can be invoked inside of arbitrary control flow structures >> like IF .. THEN, so it can't use the main control-flow stack. >> >> In a memory-constrained environment, it's slightly annoying to have to >> allocate a third stack which is going to be rarely used. > >You can store the necessary information for chaining all LEAVEs within one >DO..LOOP in the forward branches you have compiled. An other solution that works with threaded code is to store a pointer past the loop as a return address on the return stack. Both LEAVE and UNLOOP are then a simply matter of dropping the right amount of return stack items. > >-- >Bernd Paysan > -- 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]
| From | Harold <hzrabbie@gmail.com> |
|---|---|
| Date | 2015-02-11 08:17 -0800 |
| Subject | Re: Control-flow stack |
| Message-ID | <99d92bd8-2220-473d-ad7a-d30feebe50b9@googlegroups.com> |
| In reply to | #36471 |
On Wednesday, February 11, 2015 at 3:34:02 AM UTC-8, Albert van der Horst wrote: > In article <mbecii$8gr$2@dont-email.me>, > Bernd Paysan <bernd.paysan@gmx.de> wrote: > >Harold wrote: > >> I think there has to be in any case a separate control-flow stack to > >> handle LEAVE correctly. LEAVE has to leave just the innermost enclosing > >> DO .. LOOP. It can be invoked inside of arbitrary control flow structures > >> like IF .. THEN, so it can't use the main control-flow stack. > >> > >> In a memory-constrained environment, it's slightly annoying to have to > >> allocate a third stack which is going to be rarely used. > > > >You can store the necessary information for chaining all LEAVEs within one > >DO..LOOP in the forward branches you have compiled. > > An other solution that works with threaded code is to store a pointer > past the loop as a return address on the return stack. Both LEAVE and > UNLOOP are then a simply matter of dropping the right amount of return > stack items. > > > > >-- > >Bernd Paysan > > > -- > 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 Albert's solution adds a run-time overhead to each DO .. LOOP. Bernd's solution is better, since it resolves the destination of each LEAVE at compile time. -- Harold
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-10 16:37 -1000 |
| Subject | Re: Control-flow stack |
| Message-ID | <BsCdnTa_a_UcXUfJnZ2dnUU7-TOdnZ2d@supernews.com> |
| In reply to | #36451 |
On 2/10/15 2:58 PM, Harold wrote: > On Tuesday, February 10, 2015 at 2:04:42 PM UTC-8, Gerry wrote: >> On 10/02/2015 14:29, Anton Ertl wrote: >>> albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>>> In article <mbcshk$nri$1@dont-email.me>, >>>> Alex McDonald <blog@rivadpm.com> wrote: >>>>> Where this wouldn't work is >>>>> >>>>> : foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >>>>> .. ; >>>>> >>>>> Here the control flow, if on the data stack, has pushed down the literals >>>>> and we can't get at them. Are you claiming this is idiomatic, with use of >>>>> LITERAL inside a control flow where the literal value is put on the stack >>>>> before it? >>>>> >>>> >>>> If Hugh isn't, I am. And it is a pitfall because one needs to read the >>>> standard very carefully to realize that : might leave something >>>> on the control stack. >>> >>> You mean the data stack, and the case you are thinking of is not the >>> one Alex McDonald presented as example. What you are thinking of is >>> simething like >>> >>> buf-size maxbuffer - : foo literal + ; >>> >>> Here Forth-94 says: >>> >>> |6.1.0450 : colon CORE\ >>> | ( C: "<spaces>name" -- colon-sys ) >>> >>> 2.2.2 "Stack notation" explains that C: stands for the control-flow >>> stack, and 3.2.3.2 "Control-flow stack" explains that the control-flow >>> stack may be implemented using the data stack. >>> >>> I don't think this needs more careful reading than other aspects of >>> the standard. >>> >>> It seems to me that using the data stack as control-flow stack is >>> common practice (are there any exceptions?). >> >> Yes, my system has a separate stack, used for control-flow and >> information about locals during compilation. Like Hugh I have found use >> of the data stack for control-flow an irritation in the past but live >> with the restriction. Anyway there are workarounds using DEPTH with PICK >> or ROLL, alternatively using Michael Gassanenko's PASS >> >> : pass >r ' execute r> ; immediate >> 123 pass : foo literal ; foo . >> s" Hello" pass pass : bar sliteral ; bar type >> >>> Tightening the standard >>> to disallow a separate control-flow stack would not give progammers a >>> lot of additional freedom, because all the control-flow stack items >>> are opaque and the number of cells they contain is not standardized; >>> but it would have the following effects: >>> >>> * No need to document the possibility of a separate control-flow >>> stack. The standard becomes easier to understand. >>> >>> * Programmers could use DEPTH to find out the size of an individual >>> control-flow stack item, and then copy it, store it to memory, or >>> otherwise manipulate it. >> >> >>> This is probably ok for many compilers, >>> but other compilers might have been written with the assumption that >>> only the standard control-flow stack manipulation words are used for >>> dealing with control-flow stack items, and would not work with the >>> programmer-written ones. Are there such compilers? >> >> Yes mine. >> >> -- >> Gerry > > I think there has to be in any case a separate control-flow stack to > handle LEAVE correctly. LEAVE has to leave just the innermost enclosing > DO .. LOOP. It can be invoked inside of arbitrary control flow > structures like IF .. THEN, so it can't use the main control-flow stack. No, LEAVE isn't specified to use the control-flow stack. It's managed by LOOP (and friends), which have the following compile-time behavior: "Resolve the destination of all unresolved occurrences of LEAVE between the location given by do-sys and the next location for a transfer of control, to execute the words following the LOOP." How this is done is up to the implementation. However, it can't be too bad, as systems have been managing for over 20 years. > In a memory-constrained environment, it's slightly annoying to have > to allocate a third stack which is going to be rarely used. More than slightly, IMO. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-10 18:57 -0800 |
| Subject | Re: Control-flow stack |
| Message-ID | <63f786a6-c813-4545-9295-0a879a6dc12f@googlegroups.com> |
| In reply to | #36457 |
On Tuesday, February 10, 2015 at 7:37:54 PM UTC-7, Elizabeth D. Rather wrote: > On 2/10/15 2:58 PM, Harold wrote: > > I think there has to be in any case a separate control-flow stack to > > handle LEAVE correctly. LEAVE has to leave just the innermost enclosing > > DO .. LOOP. It can be invoked inside of arbitrary control flow > > structures like IF .. THEN, so it can't use the main control-flow stack. > > No, LEAVE isn't specified to use the control-flow stack. It's managed by > LOOP (and friends), which have the following compile-time behavior: > "Resolve the destination of all unresolved occurrences of LEAVE between > the location given by do-sys and the next location for a transfer of > control, to execute the words following the LOOP." > > How this is done is up to the implementation. However, it can't be too > bad, as systems have been managing for over 20 years. > > > In a memory-constrained environment, it's slightly annoying to have > > to allocate a third stack which is going to be rarely used. > > More than slightly, IMO. Typical straw-man argument --- dodges the issue of meta-compiling, which she doesn't understand --- talks about LEAVE which she does understand (it is pretty simple), although it has nothing to do with the subject at hand.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-10 18:44 -0500 |
| Message-ID | <op.xtu77xp2v6dtjm@localhost> |
| In reply to | #36390 |
On Sun, 08 Feb 2015 13:13:42 -0500, <hughaguilar96@gmail.com> wrote: > On Saturday, February 7, 2015 at 6:35:37 PM UTC-7, Elizabeth D. Rather > wrote: >> The term "control flow stack" was coined in Forth94 to allow it to >> describe the functions of these control structure words without >> *mandating* an implementation using the data stack, although that >> is the most common strategy. > > By allowing the data-stack to be used as the control-flow stack, > ANS-Forth requires programmers to assume that the data-stack is the > control-flow stack in order for their programs to work on all ANS-Forth > systems --- this is effectively the same as mandating that the > data-stack be used as the control-flow stack. > > The standard needs to require that the control-flow stack behave as a > distinct stack (not to have its data intermingled with the user's data > on the data-stack) --- this is necessary for anybody to write a standard > program that assumes that the control-flow stack is distinct. If the standard requires that the control-flow stack behave as a distinct stack, is not allowed to have control-flow interleaved with user data on the data stack, and can not use the return stack because it would break threading, just how would you implement an ITC Forth when neither of the two available stacks could be used temporarily as a control-flow stack? Are you suggesting using a dedicated third stack? ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-10 14:49 -1000 |
| Message-ID | <ZYudnU7c6fCBOkfJnZ2dnUU7-LGdnZ2d@supernews.com> |
| In reply to | #36446 |
On 2/10/15 1:44 PM, Rod Pemberton wrote: > On Sun, 08 Feb 2015 13:13:42 -0500, <hughaguilar96@gmail.com> wrote: >> On Saturday, February 7, 2015 at 6:35:37 PM UTC-7, Elizabeth D. Rather >> wrote: > >>> The term "control flow stack" was coined in Forth94 to allow it to >>> describe the functions of these control structure words without >>> *mandating* an implementation using the data stack, although that >>> is the most common strategy. >> >> By allowing the data-stack to be used as the control-flow stack, >> ANS-Forth requires programmers to assume that the data-stack is the >> control-flow stack in order for their programs to work on all ANS-Forth >> systems --- this is effectively the same as mandating that the >> data-stack be used as the control-flow stack. >> >> The standard needs to require that the control-flow stack behave as a >> distinct stack (not to have its data intermingled with the user's data >> on the data-stack) --- this is necessary for anybody to write a standard >> program that assumes that the control-flow stack is distinct. > > If the standard requires that the control-flow stack behave as a distinct > stack, is not allowed to have control-flow interleaved with user data on > the data stack, and can not use the return stack because it would break > threading, just how would you implement an ITC Forth when neither of the > two available stacks could be used temporarily as a control-flow stack? > Are you suggesting using a dedicated third stack? ... That's the implication. A thoroughly unnecessary complication, IMO, since the issues arise extremely rarely and are easy to handle once noticed. IMO this is only a big flap because some people don't understand that it's only in existence during compilation and doesn't "intermingle" with user data during the *execution* of a program. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-10 18:16 -0800 |
| Message-ID | <f0b021c8-f31e-4e30-b73c-dc8ae62c83ed@googlegroups.com> |
| In reply to | #36449 |
On Tuesday, February 10, 2015 at 5:49:34 PM UTC-7, Elizabeth D. Rather wrote: > On 2/10/15 1:44 PM, Rod Pemberton wrote: > > Are you suggesting using a dedicated third stack? ... > > That's the implication. A thoroughly unnecessary complication, IMO, > since the issues arise extremely rarely and are easy to handle once > noticed. Elizabeth Rather apparently doesn't know what a meta-compiling word is --- somebody on the ANS-Forth presumably does, because the concept of the control-flow stack was introduced into the ANS-Forth standard, but whoever it was didn't have the authority to make it standard, so it became a "may" that has to be ignored for a program to be standard (anybody who assumes that a "may" feature is available has a compiler dependency, and hence must forget about portability, although portability was the point of having a standard at all). I have a lot of meta-compiling words in the novice package that a novice (you!) could study --- <1ARRAY> and <ARY> for example --- notice the use of locals to hold values for LITERAL, as this is my work-around for the ANS-Forth failure. > IMO this is only a big flap because some people don't > understand that it's only in existence during compilation and doesn't > "intermingle" with user data during the *execution* of a program. This is typical Elizabeth Rather rhetoric --- claim that I (presumably the "some people") have a complete ignorance of Forth (which would actually make it impossible for me to write even the most rudimentary program) --- divert attention away from her own ignorance of meta-compiling with a straw-man argument. She is hoping that her sycophants will spring into action and bludgeon me with tedious condescending lectures on how control-flow data doesn't intermingle with user data during the *execution* of a program (Alex McDonald will pompously state that I have a "serious misunderstanding of how pointers work") --- dozens of posts later the thread will fizzle out under this great steaming pile of cult-behavior.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-02-11 00:35 -0800 |
| Message-ID | <855de363-e01a-44fb-b8cb-afcae56af8cb@googlegroups.com> |
| In reply to | #36449 |
On Wednesday, 11 February 2015 00:49:34 UTC, Elizabeth D. Rather wrote: > That's the implication. A thoroughly unnecessary complication, IMO, > since the issues arise extremely rarely and are easy to handle once > noticed. IMO this is only a big flap because some people don't > understand that it's only in existence during compilation and doesn't > "intermingle" with user data during the *execution* of a program. > > Cheers, > Elizabeth The restriction on passing data into a colon def is fleeting, yes. As you say, it's an issue that would occur relatively rarely. However the restriction on return stack usage within DO loops is a restriction that could be alleviated altogether with the adoption of a (permanent, not temporary) control-flow stack. Had it been adopted, it would have rendered issues such as accessing locals inside loops much simpler. The locals would go on the return stack and vanish when the definition went out of scope. Loop frames would go on the control flow stack. Accessing locals within DO loops would not require tracking the location of the locals on the return stack, since they wouldn't move regardless of how deeply a loop(s) are nested. It's far too late now, of course. The horse bolted decades ago.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-11 09:35 +0000 |
| Message-ID | <mbf7ol$ltu$1@dont-email.me> |
| In reply to | #36463 |
on 11/02/2015 08:35:22, Mark Wills wrote: > On Wednesday, 11 February 2015 00:49:34 UTC, Elizabeth D. Rather > > wrote: >> That's the implication. A thoroughly unnecessary complication, IMO, > > wrote: >> since the issues arise extremely rarely and are easy to handle once > > wrote: >> noticed. IMO this is only a big flap because some people don't > > wrote: >> understand that it's only in existence during compilation and doesn't > > wrote: >> "intermingle" with user data during the *execution* of a program. > > wrote: >> > > wrote: >> Cheers, > > wrote: >> Elizabeth > wrote: > > The restriction on passing data into a colon def is fleeting, yes. > As you say, it's an issue that would occur relatively rarely. > However the restriction on return stack usage within DO loops is > a restriction that could be alleviated altogether with the adoption > of a (permanent, not temporary) control-flow stack. Had it been > adopted, it would have rendered issues such as accessing locals inside > loops much simpler. The locals would go on the return stack and vanish > when the definition went out of scope. Loop frames would go on the > control flow stack. Accessing locals within DO loops would not require > tracking the location of the locals on the return stack, since they > wouldn't move regardless of how deeply a loop(s) are nested. You're confusing compile time with run time. This has been a consistent theme in discussions about the placement of the control flow stack; Rod Pemberton suffers from this confusion too. At *run time* DO is allowed to have loop parameters on the return stack. There aren't a huge number of places to put such parameters at *run time*. We can't use the data stack; it would block. We can't use fixed variables; our code will become impossible. We could use another stack, but then *at run time* anywhere we had a DO LOOP we'd require a data stack, a return stack and a loop parameters stack. At *compile time* we have two issues. 1) We have a set of *compile time* DO parameters. They can be on the control flow stack or they can be buried temporarily in the code we're generating for DO (normally in the branch pointers). There may be none -- the standard doesn't say and it doesn't care. It just says that there's this thing called DO-SYS and it's on the control flow stack at *compile time*. Many Forth compilers choose to use the control stack route as the space in the generated code may not be ebough; it's certainly a problem in my Forth. The control stack only exists at *compile time* but if implemented on the data stack (to avoid having 3 stacks) then it blocks *compile time* use of values on the stack. 2) This MAY not work in ANS: ... >R DO R@ ... The reason is that at *compile time* we have to account for the *run time* loop parameters on the data stack. It is possible to calculate, but in complicates R@ and makes R> very difficult indeed. Locals may also appear on the stack at *run time*. They too can be accounted for at *compile time* but is again adds significant overhead to the *compile time* action of R@, and R> will normally be far too hard. > > It's far too late now, of course. The horse bolted decades ago. > Which horse? The *compile time* horse or the *run time* horse?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-02-11 03:06 -0800 |
| Message-ID | <201526d2-6a7a-4d3f-a982-ef0b1fd0ff42@googlegroups.com> |
| In reply to | #36468 |
On Wednesday, 11 February 2015 09:35:55 UTC, Alex McDonald wrote: > Which horse? The *compile time* horse or the *run time* horse? Both! Issues arise at both compile time and run-time due to the use of common stacks for differing purposes, that could have been very simplified by the use of multiple stacks. At least the standard *doesn't* say that you *can't* use multiple stacks. Still, Hugh's comment about lowest common denominator (paraphrasing Hugh) is valid IMO. It's just a shame, that's all. There's nothing we can do about it now,and I don't detect any will to look at the issue in the new 200x standard as 200x is merely an up-rev of ANS and everyone is terrified of breaking legacy code.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-11 14:27 +0000 |
| Message-ID | <mbfor0$uhs$1@dont-email.me> |
| In reply to | #36469 |
on 11/02/2015 11:06:17, Mark Wills wrote: > On Wednesday, 11 February 2015 09:35:55 UTC, Alex McDonald wrote: Please stop cutting so viciously. This is 2015 and bits are cheap. The conversation above this is important. >> Which horse? The *compile time* horse or the *run time* horse? > > Both! Issues arise at both compile time and run-time due to the use > of common stacks for differing purposes, that could have been very > simplified by the use of multiple stacks. How simplified? Let's do run time. At run time we want the simplest model achievable, because the code may need to run on seriously constrained hardware. It's a desirable attribute even on fat and happy systems. A common approach where 2 stacks are required is to have an area of memory; one stack grows from the bottom up, the other from the top down. (The same thinking is why the x86 has a hardware implemented downward growing stack. Data at the bottom up and stack at the top down.) Go ahead and add a third runtime stack and make it efficent in terms of space and execution please. Remember, all this run time 3rd stack overhead is just so we can support DO LOOP. That's all, just support for DO LOOP. Nothing else. At compile time, the issue is even simpler (for DO at least). I can't think of a single reason to want a value off the data stack underneath the control flow DO-SYS. : FOO [ <some value> ] ... DO [ <some value> ] LITERAL ... LOOP ... ; You want a third & separate control stack at compile time to be able to do that? Use a constant or a literal and be done with it. > > At least the standard *doesn't* say that you *can't* use multiple > stacks. That's because a good standard doesn't force you to implement something in only one way. > Still, Hugh's comment about lowest common denominator > (paraphrasing Hugh) is valid IMO. It's just a shame, that's all. Hugh's a hate filled balloon. He hates Elizabeth Rather, he hates ANS, that's how he wants to read it and he hates you for telling him otherwise, he hates standards or getting suggestions to work around his crazy needs, he's spent the last 5 years cooking up his own nutjob standard, and now he's whizzed off and whacked up some whackaloon code and now he's shouting about meta-compilation. And none of us has seen this huffalumph he keeps describing but not showing. You and Rod are wrong about LCD for different reasons, since neither of you understand what he's saying (and I struggle to read & understand his stuff too, since 99% of it is dribble). Unfortunately, you don't appear to understand what the rest of us are saying either. > There's nothing we can do about it now,and I don't detect any will to > look at the issue in the new 200x standard as 200x is merely an up-rev > of ANS and everyone is terrified of breaking legacy code. > About the only area where a separate stack has benefits is the floating point stack. Even that was contentious. See here for a discussion; http://www.forth200x.org/fp-stack.html. Any recommendation to mandate the control flow stack as a separate stack will be equally so. I suspect you'd have much more support if you proposed the opposite of what you want and ask that the control flow stack was the data stack. That's because this solution of yours won't fix the "problems" you imagine, especially the run time non-issues, since (a) the control flow stack is a compile time only requirement and (b) the DO constraints are an "understand at compile time what's going on at run time" problem. Sorry to be so brutal about this, but you really have to understand the issues first, and I remain unconvinced that you have grasped that your solution is a bigger pain in the butt than the problem you keep misdescribing.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-11 14:40 +0000 |
| Message-ID | <mbfpj1$2ao$1@dont-email.me> |
| In reply to | #36472 |
on 11/02/2015 14:27:18, "Alex McDonald" wrote: > on 11/02/2015 11:06:17, Mark Wills wrote: >> On Wednesday, 11 February 2015 09:35:55 UTC, Alex McDonald wrote: > > Please stop cutting so viciously. This is 2015 and bits are cheap. The > conversation above this is important. > >>> Which horse? The *compile time* horse or the *run time* horse? >> >> Both! Issues arise at both compile time and run-time due to the use >> of common stacks for differing purposes, that could have been very >> simplified by the use of multiple stacks. > > How simplified? Let's do run time. > > At run time we want the simplest model achievable, because the code > may need to run on seriously constrained hardware. It's a desirable > attribute even on fat and happy systems. > > A common approach where 2 stacks are required is to have an area of > memory; one stack grows from the bottom up, the other from the top > down. (The same thinking is why the x86 has a hardware implemented > downward growing stack. Data at the bottom up and stack at the top > down.) > > Go ahead and add a third runtime stack and make it efficent in terms > of space and execution please. Remember, all this run time 3rd stack > overhead is just so we can support DO LOOP. That's all, just support > for DO LOOP. Nothing else. > > At compile time, the issue is even simpler (for DO at least). I can't > think of a single reason to want a value off the data stack underneath > the control flow DO-SYS. > >: FOO [ <some value> ] ... DO [ <some value> ] LITERAL ... LOOP ... ; My example was a non-example. Try again; 20 : FOO ... DO [ ( somehow fetch the 20 ) ] LITERAL ... LOOP ... ; > > You want a third & separate control stack at compile time to be able > to do that? Use a constant or a literal and be done with it. > >> >> At least the standard *doesn't* say that you *can't* use multiple >> stacks. > > That's because a good standard doesn't force you to implement > something in only one way. > >> Still, Hugh's comment about lowest common denominator >> (paraphrasing Hugh) is valid IMO. It's just a shame, that's all. > > Hugh's a hate filled balloon. He hates Elizabeth Rather, he hates ANS, > that's how he wants to read it and he hates you for telling him > otherwise, he hates standards or getting suggestions to work around > his crazy needs, he's spent the last 5 years cooking up his own nutjob > standard, and now he's whizzed off and whacked up some whackaloon code > and now he's shouting about meta-compilation. And none of us has seen > this huffalumph he keeps describing but not showing. > > You and Rod are wrong about LCD for different reasons, since neither > of you understand what he's saying (and I struggle to read & > understand his stuff too, since 99% of it is dribble). Unfortunately, > you don't appear to understand what the rest of us are saying either. > >> There's nothing we can do about it now,and I don't detect any will to >> look at the issue in the new 200x standard as 200x is merely an up-rev >> of ANS and everyone is terrified of breaking legacy code. >> > > About the only area where a separate stack has benefits is the > floating point stack. Even that was contentious. See here for a > discussion; http://www.forth200x.org/fp-stack.html. Any recommendation > to mandate the control flow stack as a separate stack will be equally > so. I suspect you'd have much more support if you proposed the > opposite of what you want and ask that the control flow stack was the > data stack. > > That's because this solution of yours won't fix the "problems" you > imagine, especially the run time non-issues, since (a) the control > flow stack is a compile time only requirement and (b) the DO > constraints are an "understand at compile time what's going on at run > time" problem. > > Sorry to be so brutal about this, but you really have to understand > the issues first, and I remain unconvinced that you have grasped that > your solution is a bigger pain in the butt than the problem you keep > misdescribing. > > >
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-12 20:02 -0500 |
| Message-ID | <op.xty06ba4v6dtjm@localhost> |
| In reply to | #36468 |
On Wed, 11 Feb 2015 04:35:55 -0500, Alex McDonald <blog@rivadpm.com> wrote: > You're confusing compile time with run time. This has > been a consistent theme in discussions about the > placement of the control flow stack; ... > Rod Pemberton suffers from this confusion too. The only point of confusion here was that I was using the computer science definition for control flow while some others here were using a Forth specific definition which differed. Fortunately, Ms. Rather just clarified in one her posts here that for Forth control flow is just the control flow used in Forth's control flow words, such as IF ELSE THEN DO LOOP etc. These only store data temporarily at compile time on the data stack, storing any permanent data in the dictionary definition for that compiled Forth word. Unfortunately, the Forth specific definition excludes the most common form of control flow used by Forth: data saved on the return stack for interpreted Forths. That is run time control flow data used to keep track of the nesting position of compiled Forth words so they can be interpreted. This data is the used to implement the threaded code equivalent of a procedure call, which is normally considered to be control flow. Forth not using standard computer science terminology has been a point of contention, not just by me, but with many others who've attempted to understand or develop Forth. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-13 11:42 +0000 |
| Message-ID | <mbknua$hr5$1@dont-email.me> |
| In reply to | #36524 |
on 13/02/2015 01:02:21, "Rod Pemberton" wrote: > On Wed, 11 Feb 2015 04:35:55 -0500, Alex McDonald <blog@rivadpm.com> > wrote: > >> You're confusing compile time with run time. This has >> been a consistent theme in discussions about the >> placement of the control flow stack; > ... > >> Rod Pemberton suffers from this confusion too. > > The only point of confusion here was that I was using > the computer science definition for control flow while > some others here were using a Forth specific definition > which differed. The definitions don't differ. > > Fortunately, Ms. Rather just clarified in one her > posts here that for Forth control flow is just the > control flow used in Forth's control flow words, > such as IF ELSE THEN DO LOOP etc. These only store > data temporarily at compile time on the data stack, > storing any permanent data in the dictionary > definition for that compiled Forth word. > > Unfortunately, the Forth specific definition excludes > the most common form of control flow used by Forth: > data saved on the return stack for interpreted Forths. > That is run time control flow data used to keep track > of the nesting position of compiled Forth words so they > can be interpreted. This data is the used to implement > the threaded code equivalent of a procedure call, which > is normally considered to be control flow. > > Forth not using standard computer science terminology > has been a point of contention, not just by me, but > with many others who've attempted to understand or > develop Forth. > Control flow includes calls and returns (subroutines), if/then/else, loops, case and switch, interrupts; in fact any flow that's not linear. Anything that takes a jump. The control flow article on wikipedia has a few issues, but it too disagrees with your narrow formulation. Control flow analysis is normally a compile time activity, not a run time activity. In this area, Forth is using the standard termnology and you are not. > > Rod Pemberton >
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-13 07:44 -0500 |
| Message-ID | <op.xtzxovk4v6dtjm@localhost> |
| In reply to | #36531 |
On Fri, 13 Feb 2015 06:42:38 -0500, Alex McDonald <blog@rivadpm.com> wrote: > on 13/02/2015 01:02:21, "Rod Pemberton" wrote: >> On Wed, 11 Feb 2015 04:35:55 -0500, Alex McDonald <blog@rivadpm.com> >> wrote: >>> You're confusing compile time with run time. This has >>> been a consistent theme in discussions about the >>> placement of the control flow stack; >> ... >> >>> Rod Pemberton suffers from this confusion too. >> >> The only point of confusion here was that I was using >> the computer science definition for control flow while >> some others here were using a Forth specific definition >> which differed. > > The definitions don't differ. 1) That's not what Ms. Rather just said. Do you take issue with her understanding? I've notice you seem to take issue with what she says, but only in response to others. You never seem to take a direct confrontation against any of her statements. 2) That means my usage in the past has always been correct, and your persistent claims that it was wrong was incorrect. >> Fortunately, Ms. Rather just clarified in one her >> posts here that for Forth control flow is just the >> control flow used in Forth's control flow words, >> such as IF ELSE THEN DO LOOP etc. These only store >> data temporarily at compile time on the data stack, >> storing any permanent data in the dictionary >> definition for that compiled Forth word. >> >> Unfortunately, the Forth specific definition excludes >> the most common form of control flow used by Forth: >> data saved on the return stack for interpreted Forths. >> That is run time control flow data used to keep track >> of the nesting position of compiled Forth words so they >> can be interpreted. This data is the used to implement >> the threaded code equivalent of a procedure call, which >> is normally considered to be control flow. >> >> Forth not using standard computer science terminology >> has been a point of contention, not just by me, but >> with many others who've attempted to understand or >> develop Forth. >> > > Control flow includes calls and returns (subroutines), > if/then/else, loops, case and switch, interrupts; in > fact any flow that's not linear. Anything that takes a jump. That is both the computer science definition and what I always used until Ms. Rather clarified with the narrow definition. You've *persistently* claimed this was incorrect. I'm now confused by your perspective of what you believe is incorrect both currently and in the past. > The control flow article on wikipedia has a few issues, > but it too disagrees with your narrow formulation. Where or what exactly, in your opinion? > In this area, Forth is using the standard termnology > and you are not. From what you just stated, I *WAS* using the correct definition, a definition which you have claimed was wrong repeatedly ... Make up your mind about what you think, or explain what you think so others can understand what you mean is incorrect, or simply stop replying. Ms. Rather just clarified with the a narrower definition for Forth which disagrees with what you're now stating. Clearly, you think something is wrong with both my past understanding of control flow for all languages, which is correct according to what you just posted, and something is also wrong with my current narrower understanding for Forth that Ms. Rather posted. Instead of making claims that something is incorrect and stating what is correct, perhaps you should state what is incorrect too. At his point, you've claimed that everything I've understood to be wrong about control flow, repeatedly, but just stated what I understand to be correct is correct. This is a contradiction or moving target definition that I can't resolve without you being more responsive and precise. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web