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 | 11 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-13 14:20 +0000 |
| Message-ID | <mbl16q$mt5$1@dont-email.me> |
| In reply to | #36534 |
on 13/02/2015 12:44:47, "Rod Pemberton" wrote: > 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: > > wrote: >>> On Wed, 11 Feb 2015 04:35:55 -0500, Alex McDonald <blog@rivadpm.com> > > wrote: >>> wrote: > 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. Please quote her. I've not seen any statements from her with which I disagree (with the exception of getting a value on the data stack after control-sys; two others picked her up on that, which is more than sufficient). > > 2) That means my usage in the past has always been correct, > and your persistent claims that it was wrong was incorrect. No, since you said this upthread: <quote> Forth usually uses two stacks, one for data and another for control flow. The control flow stack is called the "return" stack. C usually uses one stack for both data and control flow. So, control flow is *not* interleaved on a single stack like for C. It's on it's own stack. </quote> That's wrong. And this; <quote> 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? </quote> which is also wrong. > >>> 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. "Run time control flow data" doesn't have the meaning you think it has, since we're not talking about dynamic or hotspot compilation. You mean return address; in an ITC or DTC that is the next token in the thread. This "run time" is where you keep comng off the rails. Control flow is compile time data that tells us about run time flows, not data that is used and controls the flow at run time. >>> >>> 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. Where? > 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? It's a mess with far too many language specific examples. > >> 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. > I'm OK that I can't explain to your satisfaction, since it's not going to make much of a difference. > > Rod Pemberton >
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-13 10:32 -1000 |
| Message-ID | <E7ednTGU5IPgwkPJnZ2dnUU7-N-dnZ2d@supernews.com> |
| In reply to | #36537 |
On 2/13/15 4:20 AM, Alex McDonald wrote: > on 13/02/2015 12:44:47, "Rod Pemberton" wrote: >> 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: >>> wrote: >>>> On Wed, 11 Feb 2015 04:35:55 -0500, Alex McDonald <blog@rivadpm.com> >>> wrote: >>>> wrote: >> 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. > > Please quote her. I've not seen any statements from her with which I > disagree (with the exception of getting a value on the data stack after > control-sys; two others picked her up on that, which is more than > sufficient). I'll try to clarify. The term "control flow" does, indeed, have a larger meaning in computer science that comprehends both the call/return logic in a program as well as the flow of execution within a single colon definition. However, the term "control flow stack" in Forth is fairly specific (from Forth200x): |____________________ 3.2.3.2 Control-flow stack The control-flow stack is a last-in, first out list whose elements define the permissible matchings of control flow words and the restrictions imposed on data-stack usage during the compilation of control structures. The elements of the control-flow stack are system-compilation data types. ____________________| It is referenced only in the following definitions: BEGIN, DO, IF, :NONAME (relevant to the position of colon-sys on the data stack in implementations where the data stack is the control-flow stack), ?DO, CS-PICK, CS-ROLL. The term "control flow" is also key to the "system-compilation data types" such as orig and dest (Table 3.1), discussed more thoroughly in 3.1.5.1 System-compilation types. I note that the term "control flow" does *not* appear in the definition of the Return Stack (2.1), and Section 2.2.2 specifically notes: |________ The control-flow-stack stack-id is “C:”, the data-stack stack-id is “S:”, and the return-stack stack-id is “R:”. ________| Although the standard might well benefit from adding "control-flow" to the Definition of Terms section, I believe the text does make a very clear distinction between the general computer science usage of "control flow" and the very specific intent of this term in Forth (or, at least, Forth standards) for meaning management of various control-flow structures *within definitions* at compile-time. Having a language-specific understanding of a term isn't either unusual or inappropriate, providing the definitions are clarified within the language documentation. After all, Forth uses the words "word" and "definition" in very specific senses, as well. 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 | "Rod Pemberton" <bork@lllljunkqwer.cpm> |
|---|---|
| Date | 2015-03-29 16:27 -0400 |
| Message-ID | <op.xv90f4k1wa0t4m@localhost> |
| In reply to | #36537 |
On Fri, 13 Feb 2015 09:20:46 -0500, Alex McDonald <blog@rivadpm.com> wrote: > on 13/02/2015 12:44:47, "Rod Pemberton" wrote: >> 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: >> > wrote: >>>> On Wed, 11 Feb 2015 04:35:55 -0500, Alex McDonald <blog@rivadpm.com> >> > wrote: >>>> wrote: >> 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. > > Please quote her. I've not seen any statements from her with which I > disagree (with the exception of getting a value on the data stack after > control-sys; two others picked her up on that, which is more than > sufficient). Please, re-read. She said my understanding of flow control in regards to Forth was incorrect and provided a narrower explanation. You took offense to my use of her explanation, immediately afterwards. >> 2) That means my usage in the past has always been correct, >> and your persistent claims that it was wrong was incorrect. > > No, since you said this upthread: > > <quote> > Forth usually uses two stacks, one for data and another for control > flow. The control flow stack is called the "return" stack. C usually > uses one stack for both data and control flow. So, control flow is > *not* interleaved on a single stack like for C. It's on it's own stack. > </quote> > > That's wrong. How is that wrong? I.e., to what exactly, do you take an exception? At best, the final sentence could use a trivial clarification. > And this; > > <quote> > 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? > </quote> > > which is also wrong. How can a question be wrong? ... Honestly, I've never heard anyone ever declare a question to be wrong before. That's a first. This appears to have been taken out-of-context by requoting it here without the related context and due to ignoring the fact it was a question of someone else. This question was in reply to Hugh and asks him about what he was doing. Please, re-read. > "Run time control flow data" doesn't have the meaning you think it has, Apparently, it does. > since we're not talking about dynamic or hotspot compilation. Now, you're introducing concepts completely extraneous to Forth ... > You mean return address; in an ITC or DTC that is the next token > in the thread. The return address is clearly not the token itself which is what you wrote. I'll take it that you meant: "... that is the [address of] the next token in the thread." > This "run time" is where you keep comng off the rails. > Control flow is compile time data that tells us about > run time flows, not data that is used and controls the > flow at run time. No. That's completely wrong. Control flow is the language syntax and related components which controls the non-linear flow of the program at run time. >>>> 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. > > Where? You must've missed some posts or TL;DR'd as usual. Please, check with Google Groups. >> 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? > > It's a mess with far too many language specific examples. Yes, every time I attempt to get a reason or explanation from you other than a simple proclamation of: "That's wrong!", without any supportive proof, it never happens. It's really confusing at to what you mean if you don't explain. > I'm OK that I can't explain to your satisfaction, > since it's not going to make much of a difference. I don't see this as a matter of explaining to my satisfaction, but rather you not explaining anything at all, just declaring what you perceive as incorrectness to be incorrect. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-03-29 22:46 +0100 |
| Message-ID | <mf9rpl$qku$1@dont-email.me> |
| In reply to | #37737 |
on 29/03/2015 21:27:30, "Rod Pemberton" wrote: > On Fri, 13 Feb 2015 09:20:46 -0500, Alex McDonald <blog@rivadpm.com> > > wrote: >> on 13/02/2015 12:44:47, "Rod Pemberton" wrote: > > wrote: [snip] > >>> 2) That means my usage in the past has always been correct, >>> and your persistent claims that it was wrong was incorrect. >> >> No, since you said this upthread: >> >> <quote> >> Forth usually uses two stacks, one for data and another for control >> flow. The control flow stack is called the "return" stack. C usually >> uses one stack for both data and control flow. So, control flow is >> *not* interleaved on a single stack like for C. It's on it's own stack. >> </quote> >> >> That's wrong. > > How is that wrong? I.e., to what exactly, do you take an exception? > At best, the final sentence could use a trivial clarification. Read "3.2.3 Stacks" in the standard. In particular, note that what you call the control flow stack the standard calls the return stack. Forth has a seperate control-flow stack, which is a compile time only stack; it is commoinly implemented on the data stack. http://lars.nocrew.org/dpans/dpans3.htm#3.2.3 > >> And this; >> >> <quote> >> 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? >> </quote> >> >> which is also wrong. > > How can a question be wrong? ... Honestly, I've never heard anyone > ever declare a question to be wrong before. That's a first. Of course a question can be wrong. "What kind of cheese is the moon made of?" See 3.2.3 Stacks again. [snip]
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-03-29 15:24 -1000 |
| Message-ID | <MbSdncpmI_0lOIXInZ2dnUU7-f2dnZ2d@supernews.com> |
| In reply to | #37741 |
On 3/29/15 11:46 AM, Alex McDonald wrote: > on 29/03/2015 21:27:30, "Rod Pemberton" wrote: >> On Fri, 13 Feb 2015 09:20:46 -0500, Alex McDonald <blog@rivadpm.com> >>> wrote: >>> on 13/02/2015 12:44:47, "Rod Pemberton" wrote: >>> wrote: > > [snip] > >> >>>> 2) That means my usage in the past has always been correct, >>>> and your persistent claims that it was wrong was incorrect. >>> >>> No, since you said this upthread: >>> >>> <quote> >>> Forth usually uses two stacks, one for data and another for control >>> flow. The control flow stack is called the "return" stack. C usually >>> uses one stack for both data and control flow. So, control flow is >>> *not* interleaved on a single stack like for C. It's on it's own stack. >>> </quote> >>> >>> That's wrong. >> >> How is that wrong? I.e., to what exactly, do you take an exception? >> At best, the final sentence could use a trivial clarification. > > Read "3.2.3 Stacks" in the standard. In particular, note that what you > call the control flow stack the standard calls the return stack. Forth > has a seperate control-flow stack, which is a compile time only stack; it > is commoinly implemented on the data stack. > http://lars.nocrew.org/dpans/dpans3.htm#3.2.3 The problem is, the term "control flow" is being used in two different senses here. Rod is using it to mean logical execution flow from one word to another, which in Forth typically involves the Return Stack. However, when Forth standards speak of a "control flow stack" they are using a much narrower and Forth-specific definition, meaning the stack used by the compiler during compilation to keep track of the addresses used to build structures such as IF ... ELSE ... THEN and DO ... LOOP. That is virtually always the data stack during compilation. >>> And this; >>> >>> <quote> >>> 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? >>> </quote> >>> >>> which is also wrong. >> >> How can a question be wrong? ... Honestly, I've never heard anyone >> ever declare a question to be wrong before. That's a first. What's wrong is that you are confusing the general computing sense of "control flow" with the narrow, Forth-specific meaning of the "control-flow stack." Let me try an example. Consider the definition (I'm going to assume ITC here): : FOO ( n -- ) >R 10 0 DO I . LOOP R> DROP ; When the compiler processes this definition, the compile-time action of DO is to push the address following the run-time code for DO onto the "control-flow stack", which is normally the data stack. The compile-time action of LOOP is to expect an address on the control-flow (Data) stack and compile a conditional branch back to that address. All the references to the Return Stack such as >R and R> are just compiled references. The Return Stack is not involved, except for managing the execution of the compiler. Now if you *execute* 5 FOO, the 5 is pushed on the Return Stack at the beginning and taken off at the end. DO pushes loop parameters onto the Return Stack, I references them, and LOOP takes them off when the loop terminates. You cannot access the 5 during the loop because the loop parameters are there. The Forth "control-flow stack" does not *exist* during the *execution* of FOO, because it was used to *compile* FOO, and that was minutes, weeks, or years ago. Perhaps it is unfortunate that the Forth standards use the term "control-flow stack" for the place the compiler uses to pass addresses used by compiler directives during compile time, but there's now over 20 years of use of this term, and it would be even more confusing to change now, IMO. Hope this helps, 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-03-30 04:44 -0700 |
| Message-ID | <ededa5af-51c3-46df-a125-2da58d5015fc@googlegroups.com> |
| In reply to | #37747 |
On Sunday, March 29, 2015 at 6:24:10 PM UTC-7, Elizabeth D. Rather wrote: > However, when Forth standards speak of a "control flow stack" they are > using a much narrower and Forth-specific definition, meaning the stack > used by the compiler during compilation to keep track of the addresses > used to build structures such as IF ... ELSE ... THEN and DO ... LOOP. > That is virtually always the data stack during compilation. This is a bug in the standard --- the control-flow data gets in the way of the user's data on the (ahem) data-stack. For 20 years, Forth programmers have been working around your bug. Here is an example of your sycophant Bernd working around your bug: https://groups.google.com/forum/#!topic/comp.lang.forth/THP64AeGuS0 On Sunday, March 22, 2015 at 2:11:03 PM UTC-7, Bernd Paysan wrote: > : compose ( xt1 xt2 -- xt3 ) swap >r >r > :noname r> compile, r> compile, postpone ; ; Although he is on the Forth-200x committee, he is not going to fix the bug --- he knows that you will kick him off the committee if he admits that there are bugs in ANS-Forth --- he would rather just continue writing convoluted confusing code like COMPOSE above (the first three decades were the worst, but it has become habit now). > Hope this helps, > Elizabeth Fixing the bug would help --- but then you would have to admit that it was a bug, and has been a bug for 20 years --- you aren't going to do this.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-03-30 15:33 +0100 |
| Message-ID | <mfbmq3$ikc$1@dont-email.me> |
| In reply to | #37750 |
on 30/03/2015 12:44:12, high wrote: > > This is a bug in the standard --- the control-flow data gets in the Do you know what a bug is? > way of the user's data on the (ahem) data-stack. Why don't you propose & write up a change to the standard? Here's a set of replies I've prepared for you. 1. I'm developing my own language. Why would I care about a standard? 2. I don't want to support Forth Inc's evil empire by fixing ANS Forth. 3. Elizabeth Rather will employ a bunch of homosexual asassins to hunt me down. 4. I'd prefer to be able to whine a bit more. 5. Anton Ertl would cry becuase he's not a programmer and he wouldn't know how to fix Gforth 6. Russian Jews 7. It's a pointer, and I don't understand pointers. Pick one. My money's on 7.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-11 18:03 +0000 |
| Message-ID | <2015Feb11.190319@mips.complang.tuwien.ac.at> |
| In reply to | #36463 |
Mark Wills <markwills1970@gmail.com> writes:
>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.
I think you can put loop-sys on a separate stack if you want. It's an
opaque type, and we don't have any standard way to make it even a
little transparent (we have DEPTH for the data stack, which allows us
to count the number of cells on the data stack, but no equivalent for
the return stack). And some systems make good use of that.
Concerning your motivation, if you want to have locals on a different
stack from loop-sys, the easy way to do it is to have a separate stack
for locals (used in Gforth, but mainly for a different reason); then
you can put loop-sys on the return stack without affecting the locals.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-02-12 00:16 +0100 |
| Message-ID | <mbgnrb$l1v$1@dont-email.me> |
| In reply to | #36481 |
Anton Ertl wrote: > Concerning your motivation, if you want to have locals on a different > stack from loop-sys, the easy way to do it is to have a separate stack > for locals (used in Gforth, but mainly for a different reason); then > you can put loop-sys on the return stack without affecting the locals. Actually, if you mix locals and loop-sys on the same stack (as all those locals-on-the-return-stack systems do), it is pretty easy to get them to cooperate fine. Essentially, you can think of I and I' as two new locals that start their scope at DO and end it at LOOP. J and K with intermediately declaired locals are more tricky. -- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-12 07:08 +0000 |
| Message-ID | <2015Feb12.080821@mips.complang.tuwien.ac.at> |
| In reply to | #36487 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Concerning your motivation, if you want to have locals on a different
>> stack from loop-sys, the easy way to do it is to have a separate stack
>> for locals (used in Gforth, but mainly for a different reason); then
>> you can put loop-sys on the return stack without affecting the locals.
>
>Actually, if you mix locals and loop-sys on the same stack (as all those
>locals-on-the-return-stack systems do), it is pretty easy to get them to
>cooperate fine. Essentially, you can think of I and I' as two new locals
>that start their scope at DO and end it at LOOP. J and K with
>intermediately declaired locals are more tricky.
Not really. If you allow to define locals within a DO..LOOP, you also
have to deal with the issue for I (and I'); not that it's any harder
than still being able to access the earlier-defined locals (which is
not particularly hard). If you don't (as some Forth systems do),
neither I nor J nor K are a problem.
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-08 10:51 +0000 |
| Message-ID | <mb7f2m$qu$1@dont-email.me> |
| In reply to | #36375 |
on 08/02/2015 01:11:42, "Rod Pemberton" wrote: > On Sat, 07 Feb 2015 14:22:13 -0500, Alex McDonald <blog@rivadpm.com> > > wrote: >> on 07/02/2015 04:41:13, "Rod Pemberton" wrote: > > wrote: >>> On Fri, 06 Feb 2015 14:16:36 -0500, Aliaksei Chapyzhenka > > wrote: >>> <alex.drom@gmail.com> wrote: > wrote: > >>>> * I am trying to construct Stack machine code from SSA representation. >>> >>> Does your SSA representation use stack locations like registers, >>> or more like a LIFO stack? If it's for a typical language, it'll >>> be more like registers. >> >> SSA form is language neutral, and assumes an infinite memory space. It >> says nothing about registers or stacks since it can't express those >> concepts directly. > > Yes, that's exactly the problem he, and most compiler implementors, > must solve, which he asked about. Isn't it? I thought it was. Transforming SSA to or augmenting SSA for stack machine operations requires some interesing work, since there is far less immediately addressable on the stack than there is with the infinite memory SSA uses (the top 2 or 3 cells at most in our stack and a push-down temporary store in the return stack); and we want to avoid using memory, especially using it randomly and arbitrarily, where at all possible. I would suggest that SSA to Forth is as hard a problem as C to Forth, and I wish the OP well. Anton Ertl has pointed out the limited number of papers on this subject elsewhere.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.forth
csiph-web