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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-08 00:04 +0000 |
| Message-ID | <mb6965$rpj$1@dont-email.me> |
| In reply to | #36370 |
on 07/02/2015 22:51:53, Aliaksei Chapyzhenka wrote: > On Saturday, February 7, 2015 at 2:32:22 PM UTC-8, Alex McDonald >> You only require DUP SWAP >R R> and DROP. OVER and R@ along with all >> other stack juggling words can be constructed from them. > >: SWAP OVER >R >R DROP R> R> ; >: DUP >R R@ R> ; >: DROP DUP XOR XOR ; There's a canonical stack machine described here http://users.ece.cmu.edu/~koopman/stack_computers/sec3_2.html. This claims >R R> DROP DUP SWAP and OVER are the minimum set of operations that don't involve the ALU, but either SWAP or OVER can be eliminated. Five seems to be the absolute minimum whatever operations one chooses.
[toc] | [prev] | [next] | [standalone]
| From | Aliaksei Chapyzhenka <alex.drom@gmail.com> |
|---|---|
| Date | 2015-02-07 17:03 -0800 |
| Message-ID | <000c33fb-159a-4d98-bcef-9e27776d6387@googlegroups.com> |
| In reply to | #36373 |
On Saturday, February 7, 2015 at 4:04:58 PM UTC-8, Alex McDonald wrote: > on 07/02/2015 22:51:53, Aliaksei Chapyzhenka wrote: > > On Saturday, February 7, 2015 at 2:32:22 PM UTC-8, Alex McDonald > > >> You only require DUP SWAP >R R> and DROP. OVER and R@ along with all > >> other stack juggling words can be constructed from them. > > > >: SWAP OVER >R >R DROP R> R> ; > >: DUP >R R@ R> ; > >: DROP DUP XOR XOR ; > > There's a canonical stack machine described here > http://users.ece.cmu.edu/~koopman/stack_computers/sec3_2.html. This > claims >R R> DROP DUP SWAP and OVER are the minimum set of operations > that don't involve the ALU, but either SWAP or OVER can be eliminated. > Five seems to be the absolute minimum whatever operations one chooses. You are right. I see no disconnect here. If compiler/programmer targeting Hardware Forth Machine it/they should use core stack manipulation words like, DROP, DUP, >R, R>, SWAP/OVER,... until it become "singularly awkward and inefficient" and then can add one of the following advanced capabilities: 1) Literal PICK -- less human readable and may involve additional parameter stack access methods/hardware. HW Forth Machine may also limit PICK to some depth and then we back to (PICK) + (>R R>). 2) locals -- more human readable, but hides the actual implementation mechanism and may involve additional stack, or use of Return Stack as an universal local data storage.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-07 21:04 -0500 |
| Message-ID | <op.xtpuo5dlv6dtjm@localhost> |
| In reply to | #36370 |
On Sat, 07 Feb 2015 17:51:57 -0500, Aliaksei Chapyzhenka <alex.drom@gmail.com> wrote: > : SWAP OVER >R >R DROP R> R> ; This is probably not what you want. OVER usually requires more code in assembly than other operations. I.e., you've slowed down SWAP by using OVER and made SWAP dependent on OVER being implemented as a "primitive" or low-level Forth word or operation. You want to minimize use of ROT and OVER because they're complicated operations on most microprocessors relative to other simpler stack operations. They don't work well with LIFO stacks and direct access of stack items. > : DUP >R R@ R> ; This isn't a good idea either. Instead of being able to fetch the top data item on the data stack directly, you've migrated the operation to where you can, i.e., the return stack using R@ . It's better to have DUP be implemented as a "primitive" or low-level Forth word or operation. DUP is a heavily used word in Forth, at least. You can look at Philip Koopman's instruction frequencies: http://users.ece.cmu.edu/~koopman/stack_computers/sec6_3.html Anton Ertl also has Forth instruction frequencies, somewhere. > : DROP DUP XOR XOR ; That doesn't do what you think it does. DUP creates two stack items. XOR XOR converts one of them to zero. But, you still have two items on the stack, the second one being a zero. DROP needs to _reduce_ the number of items on the stack. Reducing or increasing the number of items on a stack usually requires a "primitive" or low-level Forth word or operation. I'd recommend implementing these as "primitives" or low-level Forth words or operations: > R R> DUP DROP SWAP OVER ROT Those aren't the absolute minimum since a couple of those can be eliminated, but it's close to it. Eliminating more slows down Forth code and would like slow down your code too. Optionally, you may want R@ too. R@ is not generally needed, except maybe for implementations of I and J . If you're directly accessing the stack, similar to parameters in C, you'll need PICK and the reverse operation, i.e., perhaps named PLACE . IIRC, Alex McDonald is using an optimizer, Rafts, that can determine optimal sequences for Forth words. I'm using an optimizer also. It's a highly modified, private version of Peter Sovietov's Forth Wizard: http://www.sovietov.com/app/forthwiz.html I've added a huge number of stack operations. I can select most any set of Forth stack operations, x86 style stack operations, Rob Chapman's "Stack Quarks", or use of temporary variables, etc to determine optimal sequences. I also updated it to use the return stack, so more complicated operations can be solved. E.g., for 2NIP (a b c d -- c d ), in terms of R> >R R@ DUP DROP SWAP OVER ROT -ROT rot drop rot drop > r -rot drop drop r> rot drop -rot -rot drop -rot -rot drop rot drop > r >r drop drop r> r>r swap drop r> rot dropr swap drop swap drop r> (keeps on going ...) If I don't want ROT or OVER etc I can unselect them and re-run. If you want 2NIP in terms of 2R> 2>R 2R@ 2DUP 2DROP 2SWAP 2OVER 2ROT -2ROT 2swap 2drop 2>r 2drop 2r> 2dup 2rot 2drop 2drop 2dup -2rot 2drop 2drop 2over 2rot 2drop 2drop 2>r 2drop 2r@ 2r> 2drop 2dup 2>r 2drop 2drop 2r> 2dup 2rot 2swap 2drop 2drop 2dup 2rot 2rot 2drop 2drop 2dup -2rot 2swap 2drop 2drop (keeps on going ...) An example using the return stack, e.g., 2R> (a b -- ) (R: -- a b) swap >r >r over >r >r drop dup rot >r >r drop dup rot >r drop >r dup -rot drop >r >r swap >r dup >r drop swap dup >r drop >r over >r swap drop >r over rot >r drop >r (keeps on going ...) I didn't post other solutions in terms of stack operators that I defined since you wouldn't understand what my naming means, but they're available also. E.g., directly retrieving from specific locations to specific data or return stack locations. Obviously, this optimizer doesn't find solutions using arithmetic operations or other Forth words. The Rafts optimizer Alex McDonald is using should. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-07 21:10 -0500 |
| Message-ID | <op.xtpuz4ypv6dtjm@localhost> |
| In reply to | #36377 |
On Sat, 07 Feb 2015 21:04:07 -0500, Rod Pemberton <buzz@notnotnontnooatno.cmm> wrote: > On Sat, 07 Feb 2015 17:51:57 -0500, Aliaksei Chapyzhenka > <alex.drom@gmail.com> wrote: >> : DROP DUP XOR XOR ; > > That doesn't do what you think it does. DUP creates two stack > items. XOR XOR converts one of them to zero. But, you still > have two items on the stack, the second one being a zero. > DROP needs to _reduce_ the number of items on the stack. > Reducing or increasing the number of items on a stack usually > requires a "primitive" or low-level Forth word or operation. > Correction. Scratch that. That was two XOR's. One item. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-08 10:57 +0000 |
| Message-ID | <mb7fel$288$1@dont-email.me> |
| In reply to | #36377 |
on 08/02/2015 02:04:07, "Rod Pemberton" wrote: > IIRC, Alex McDonald is using an optimizer, Rafts, that can > determine optimal sequences for Forth words. > It transforms Forth into SSA for code generation on a register machine (x86). The stack disappears to be replaced by registers and memory. It's incomplete.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-07 21:05 -0500 |
| Message-ID | <op.xtpurgd5v6dtjm@localhost> |
| In reply to | #36367 |
On Sat, 07 Feb 2015 17:09:06 -0500, Aliaksei Chapyzhenka <alex.drom@gmail.com> wrote: > On Saturday, February 7, 2015 at 1:25:31 PM UTC-8, Elizabeth D. Rather > wrote: >> On 2/7/15 11:09 AM, Aliaksei Chapyzhenka wrote: >> > It is common to store return address or loop counter there, but >> > also temporal shuffling data from parameter stack and back... >> >> : 2SWAP ROT >R ROT R> ; >> >> That is a singularly awkward and inefficient definition of 2SWAP. > > Yes, especially I we define : ROT >R SWAP R> SWAP ; If you avoid ROT and OVER in 2SWAP's definition, the next shortest sequence in *Forth* code, using low-level Forth words, is: : 2SWAP >R SWAP R> SWAP >R >R SWAP r> SWAP R> ; I can be argue that that is even less efficient. So, I'm not sure what Alex's point was. Perhaps, he meant that non-Forth stack operations could implement the sequence better ... ? > But what [else] would you do on the stack machine without PICK with > core set of Forth words: DROP DUP SWAP OVER >R R> R@ ? Without PICK and the reverse operation, perhaps PLACE , you can't directly obtain values from the stack or store values directly into the stack. You'd have to do things the Forth way, which is to move everything to the return stack, perform the save/retrieve, move everything back to the data stack from the return stack. This is why non-Forth languages don't implement stack code in this manner. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-07 22:24 +0000 |
| Message-ID | <mb63a4$3h9$1@dont-email.me> |
| In reply to | #36363 |
on 07/02/2015 21:09:21, Aliaksei Chapyzhenka wrote: > On Saturday, February 7, 2015 at 11:22:14 AM UTC-8, Alex McDonald >> on 07/02/2015 04:41:13, "Rod Pemberton" wrote: >> > On Fri, 06 Feb 2015 14:16:36 -0500, Aliaksei Chapyzhenka >> > <alex.drom@gmail.com> wrote: >> >> * [I'm trying to stay] with core Forth vocabulary (DROP, SWAP, DUP, >> >> Constant_PICK, >R, R>, ...) >> > >> > For the most part in Forth, the control stack, accessed by >R and R> , >> > acts like a single, temporary, storage register. I.e., just by having >> > fetch @ and store ! on a temporary register, e.g., A@ and A! , you can >> > eliminate much of the need for the return stack, but not all use of >> > the return stack. Any double operations, 2SWAP, etc, and loop >> > operations will need to use multiple items on the return stack. >> >> Why would double operations use multiple items on the return stack? > > Forth uses Return Stack as the universal storage. It is common to It can be used to unblock the stack but... > store ret urn address or loop counter there, but also temporal > shuffling data from pa rameter stack and back : 2SWAP ROT >R ROT R> ; > Compiler can use these >R R> operations to overcome luck of PICK > operation in order to allocate multiple local variables. It costs more > in general but possible to the arbitrary depth. ..it's not necessary that locals are on the return stack. Gforth is a case in point; it has a separate locals stack. https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Locals-implementation.html > I am providing the compiler a set of heuristics that it can use on the > targ et machine and the cost of every sequence (representing the code > size, cycl e count, or energy consumption). Including all return stack > tricks. Compile r will map SSA form into the sequence of steps. It > will also try minimizing the cost of such solution. Do you mean SSA to Forth or a Forth-like stack machine? > > --Alexey > >
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-07 11:21 -1000 |
| Message-ID | <nb-dnT9RItNdHEvJnZ2dnUU7-U-dnZ2d@supernews.com> |
| In reply to | #36362 |
On 2/7/15 9:22 AM, Alex McDonald wrote: > on 07/02/2015 04:41:13, "Rod Pemberton" wrote: >> On Fri, 06 Feb 2015 14:16:36 -0500, Aliaksei Chapyzhenka >> <alex.drom@gmail.com> wrote: >> >>> To clarify my intent: >>> * I do want allocate local variables (and phi points) on the stack >>> across the control flow. >> >> 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. > > The Forth control flow stack and the return stack (or rstack, rack) are > not the same. The control flow stack exists only at compile time. Correct. And is usually the data stack, being used by the compiler. ... >> For the most part in Forth, the control stack, accessed by >R and R> , >> acts like a single, temporary, storage register. I.e., just by having >> fetch @ and store ! on a temporary register, e.g., A@ and A! , you can >> eliminate much of the need for the return stack, but not all use of >> the return stack. Any double operations, 2SWAP, etc, and loop >> operations will need to use multiple items on the return stack. > > Why would double operations use multiple items on the return stack? In implementations I know, double operations don't use the return stack at all. 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" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-07 20:11 -0500 |
| Message-ID | <op.xtpr9tbrv6dtjm@localhost> |
| In reply to | #36362 |
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: >> On Fri, 06 Feb 2015 14:16:36 -0500, Aliaksei Chapyzhenka >> <alex.drom@gmail.com> wrote: >>> To clarify my intent: >>> * I do want allocate local variables (and phi points) on the stack >>> across the control flow. >> >> 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. > > The Forth control flow stack and the return stack (or rstack, rack) are > not the same. The control flow stack exists only at compile time. How exactly does that work for an interpreted Forth? It's two stacks are always present, even during the "compile time" of a colon definition. I.e., the return stack is used for control flow, unless Forth has a non-standard definition of control flow meaning something other than what Computer Science normally defines it as ... >>> * 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. >>> * [I'm trying to stay] with core Forth vocabulary (DROP, SWAP, DUP, >>> Constant_PICK, >R, R>, ...) >> >> For the most part in Forth, the control stack, accessed by >R and R> , >> acts like a single, temporary, storage register. I.e., just by having >> fetch @ and store ! on a temporary register, e.g., A@ and A! , you can >> eliminate much of the need for the return stack, but not all use of >> the return stack. Any double operations, 2SWAP, etc, and loop >> operations will need to use multiple items on the return stack. > > Why would double operations use multiple items on the return stack? > Sorry, 2SWAP was a bad example. Others, like 2ROT may use 2>R 2R> etc. E.g., : 2ROT 2>R 2SWAP 2R> 2SWAP ; Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-07 15:35 -1000 |
| Message-ID | <DKWdneKJys_1IEvJnZ2dnUU7-KmdnZ2d@supernews.com> |
| In reply to | #36375 |
On 2/7/15 3:11 PM, 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: >>> On Fri, 06 Feb 2015 14:16:36 -0500, Aliaksei Chapyzhenka >>> <alex.drom@gmail.com> wrote: > >>>> To clarify my intent: >>>> * I do want allocate local variables (and phi points) on the stack >>>> across the control flow. >>> >>> 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. >> >> The Forth control flow stack and the return stack (or rstack, rack) are >> not the same. The control flow stack exists only at compile time. > > How exactly does that work for an interpreted Forth? It's two stacks > are always present, even during the "compile time" of a colon definition. > I.e., the return stack is used for control flow, unless Forth has a > non-standard definition of control flow meaning something other than > what Computer Science normally defines it as ... When talking about "control flow" in Forth, we refer to control structures *within* definitions, such as BEGIN ... UNTIL, BEGIN ... WHILE ... REPEAT, DO ... LOOP, IF ... ELSE ... THEN, etc. A Forth compiler uses the "control flow stack" to handle the address to be used or patched by the later words in a structure. Thus, BEGIN at compile time leaves an address on the control flow stack which UNTIL or REPEAT will fill with the current address. This is normally the data stack being used at compile time (look at the stack representations in the Standard or other glossaries). 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. The Return Stack is used for the logical flow that in other languages is associated with subroutine or function calls. We do not call this "control flow" in Forth. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-07 16:52 -1000 |
| Message-ID | <GdydnfFXbL7tUkvJnZ2dnUU7-LGdnZ2d@supernews.com> |
| In reply to | #36376 |
On 2/7/15 3:35 PM, Elizabeth D. Rather wrote: ... > Thus, BEGIN at compile time leaves an address on the control flow stack > which UNTIL or REPEAT will fill with the current address. This is > normally the data stack being used at compile time (look at the stack > representations in the Standard or other glossaries). Further clarification: For a forward branch, such as IF or WHILE, the compiler typically compiles a branch whose destination isn't immediately known; a zero cell is compiled, and its address left on the control flow stack. A subsequent THEN, etc., which knows where the branch destination is supposed to be will go back and patch that zero to the desired address. For a backward branch, such as LOOP or UNTIL, the starting word (e.g. BEGIN) will leave the address of the next cell on the c.f.stack to be use by the terminating word to compile its branch. 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-08 10:21 -0800 |
| Message-ID | <7c2c334d-9b99-4667-a43f-74c553676ab5@googlegroups.com> |
| In reply to | #36380 |
On Saturday, February 7, 2015 at 7:52:33 PM UTC-7, Elizabeth D. Rather wrote: > On 2/7/15 3:35 PM, Elizabeth D. Rather wrote: > ... > > Thus, BEGIN at compile time leaves an address on the control flow stack > > which UNTIL or REPEAT will fill with the current address. This is > > normally the data stack being used at compile time (look at the stack > > representations in the Standard or other glossaries). > > Further clarification: For a forward branch, such as IF or WHILE, the > compiler typically compiles a branch whose destination isn't immediately > known; a zero cell is compiled, and its address left on the control flow > stack. A subsequent THEN, etc., which knows where the branch destination > is supposed to be will go back and patch that zero to the desired address. > > For a backward branch, such as LOOP or UNTIL, the starting word (e.g. > BEGIN) will leave the address of the next cell on the c.f.stack to be > use by the terminating word to compile its branch. > > Cheers, > Elizabeth All of this assumes that the compiler is non-optimizing --- that it is just compiling the source-code words into threaded-code words one-to-one and one-by-one --- this is 1970s technology. When the so-called "leading expert" on ANS-Forth, and the representative of Forth Inc., describes 1970s technology on comp.lang.forth in 2015 as the state of the art, this makes the entire Forth community look stupid --- you are dragging everybody down to your own level of incompetence --- you have been dragging down the Forth community for over three decades, and you have never made a positive contribution to Forth.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-08 20:09 +0000 |
| Message-ID | <mb8fpi$bph$1@dont-email.me> |
| In reply to | #36391 |
on 08/02/2015 18:21:18, hugj wrote: > On Saturday, February 7, 2015 at 7:52:33 PM UTC-7, Elizabeth D. Rather > wrot e: >> On 2/7/15 3:35 PM, Elizabeth D. Rather wrote: >> ... >> > Thus, BEGIN at compile time leaves an address on the control flow stack >> > which UNTIL or REPEAT will fill with the current address. This is >> > normally the data stack being used at compile time (look at the stack >> > representations in the Standard or other glossaries). >> >> Further clarification: For a forward branch, such as IF or WHILE, the >> compiler typically compiles a branch whose destination isn't immediately > >> known; a zero cell is compiled, and its address left on the control flow > >> stack. A subsequent THEN, etc., which knows where the branch destination > >> is supposed to be will go back and patch that zero to the desired address > . >> >> For a backward branch, such as LOOP or UNTIL, the starting word (e.g. >> BEGIN) will leave the address of the next cell on the c.f.stack to be >> use by the terminating word to compile its branch. >> >> Cheers, >> Elizabeth > > All of this assumes that the compiler is non-optimizing --- that it is > just compiling the source-code words into threaded-code words > one-to-one and on e-by-one --- this is 1970s technology. Can you explain how forward references are resolved in an optimizing compiler? [Hyperventilating drama queen stuff snipped]
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-08 17:15 -1000 |
| Message-ID | <7I2dnb2UeYT7u0XJnZ2dnUU7-L2dnZ2d@supernews.com> |
| In reply to | #36394 |
On 2/8/15 10:09 AM, Alex McDonald wrote: > on 08/02/2015 18:21:18, hugj wrote: >> On Saturday, February 7, 2015 at 7:52:33 PM UTC-7, Elizabeth D. Rather >> wrot e: >>> On 2/7/15 3:35 PM, Elizabeth D. Rather wrote: >>> ... >>>> Thus, BEGIN at compile time leaves an address on the control flow stack >>>> which UNTIL or REPEAT will fill with the current address. This is >>>> normally the data stack being used at compile time (look at the stack >>>> representations in the Standard or other glossaries). >>> >>> Further clarification: For a forward branch, such as IF or WHILE, the >>> compiler typically compiles a branch whose destination isn't immediately >>> known; a zero cell is compiled, and its address left on the control flow >>> stack. A subsequent THEN, etc., which knows where the branch destination >>> is supposed to be will go back and patch that zero to the desired address >>> >>> For a backward branch, such as LOOP or UNTIL, the starting word (e.g. >>> BEGIN) will leave the address of the next cell on the c.f.stack to be >>> use by the terminating word to compile its branch. >> >> All of this assumes that the compiler is non-optimizing --- that it is >> just compiling the source-code words into threaded-code words >> one-to-one and on e-by-one --- this is 1970s technology. > > Can you explain how forward references are resolved in an optimizing > compiler? It obviously depends on the strategy used by the optimizing compiler! I know at least one that uses this same method to manage the branch addresses, even though other aspects of the compilation process differ. I chose to explain the process by reference to ITC, because that's a model most folks here are familiar with, but using the stack for managing the branch destination is quite convenient and common in several alternative implementations. 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-09 12:00 +0000 |
| Message-ID | <mba7f0$tqs$1@dont-email.me> |
| In reply to | #36403 |
on 09/02/2015 03:15:50, "Elizabeth D. Rather" wrote: > On 2/8/15 10:09 AM, Alex McDonald wrote: >> on 08/02/2015 18:21:18, hugj wrote: >>> On Saturday, February 7, 2015 at 7:52:33 PM UTC-7, Elizabeth D. Rather >>> wrot e: >>>> On 2/7/15 3:35 PM, Elizabeth D. Rather wrote: >>>> ... >>>>> Thus, BEGIN at compile time leaves an address on the control flow stack >>>>> which UNTIL or REPEAT will fill with the current address. This is >>>>> normally the data stack being used at compile time (look at the stack >>>>> representations in the Standard or other glossaries). >>>> >>>> Further clarification: For a forward branch, such as IF or WHILE, the >>>> compiler typically compiles a branch whose destination isn't immediately >>>> known; a zero cell is compiled, and its address left on the control flow >>>> stack. A subsequent THEN, etc., which knows where the branch destination >>>> is supposed to be will go back and patch that zero to the desired address >>>> >>>> For a backward branch, such as LOOP or UNTIL, the starting word (e.g. >>>> BEGIN) will leave the address of the next cell on the c.f.stack to be >>>> use by the terminating word to compile its branch. >>> >>> All of this assumes that the compiler is non-optimizing --- that it is >>> just compiling the source-code words into threaded-code words >>> one-to-one and on e-by-one --- this is 1970s technology. >> >> Can you explain how forward references are resolved in an optimizing >> compiler? > > It obviously depends on the strategy used by the optimizing compiler! > I know at least one that uses this same method to manage the branch > addresses, even though other aspects of the compilation process > differ. > > I chose to explain the process by reference to ITC, because that's a > model most folks here are familiar with, but using the stack for > managing the branch destination is quite convenient and common in > several alternative implementations. > > Cheers, > Elizabeth > Elizabeth, thanks for the explanation. I was actually asking Hugh. I am pretty convinced he doesn't realise that the process is much the same. His hatred of you blinds him.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-02-09 13:05 +0000 |
| Message-ID | <54d8b08d$0$15858$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #36403 |
In article <7I2dnb2UeYT7u0XJnZ2dnUU7-L2dnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 2/8/15 10:09 AM, Alex McDonald wrote:
>> on 08/02/2015 18:21:18, hugj wrote:
>>> On Saturday, February 7, 2015 at 7:52:33 PM UTC-7, Elizabeth D. Rather
>>> wrot e:
>>>> On 2/7/15 3:35 PM, Elizabeth D. Rather wrote:
>>>> ...
>>>>> Thus, BEGIN at compile time leaves an address on the control flow stack
>>>>> which UNTIL or REPEAT will fill with the current address. This is
>>>>> normally the data stack being used at compile time (look at the stack
>>>>> representations in the Standard or other glossaries).
>>>>
>>>> Further clarification: For a forward branch, such as IF or WHILE, the
>>>> compiler typically compiles a branch whose destination isn't immediately
>>>> known; a zero cell is compiled, and its address left on the control flow
>>>> stack. A subsequent THEN, etc., which knows where the branch destination
>>>> is supposed to be will go back and patch that zero to the desired address
>>>>
>>>> For a backward branch, such as LOOP or UNTIL, the starting word (e.g.
>>>> BEGIN) will leave the address of the next cell on the c.f.stack to be
>>>> use by the terminating word to compile its branch.
>>>
>>> All of this assumes that the compiler is non-optimizing --- that it is
>>> just compiling the source-code words into threaded-code words
>>> one-to-one and on e-by-one --- this is 1970s technology.
>>
>> Can you explain how forward references are resolved in an optimizing
>> compiler?
>
>It obviously depends on the strategy used by the optimizing compiler! I
>know at least one that uses this same method to manage the branch
>addresses, even though other aspects of the compilation process differ.
>
>I chose to explain the process by reference to ITC, because that's a
>model most folks here are familiar with, but using the stack for
>managing the branch destination is quite convenient and common in
>several alternative implementations.
For example the same technique is used in assembler programs.
Quite a few Forth assembler supply supply structured constructs
similar to this style
begin, ; Remember program counter
ld, ax, my_buffer [si],
mov, ax, bx,
..
dec, cx, ; May set zero flag.
Z until, ; Jump back if not zero.
Note the jump this translates to.
Because the assembler inverts error conditions as appropriate
this is much less error prone.
You need a Forth mindset (and a stack) to add this to an assembler.
Outside of Forth assemblers it is rare.
>
>Cheers,
>Elizabeth
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2015-02-10 16:01 +1100 |
| Message-ID | <mbc38o$unn$1@speranza.aioe.org> |
| In reply to | #36413 |
Albert van der Horst wrote: > [...] > For example the same technique is used in assembler programs. > Quite a few Forth assembler supply supply structured constructs > similar to this style > > begin, ; Remember program counter > ld, ax, my_buffer [si], > mov, ax, bx, > .. > dec, cx, ; May set zero flag. > Z until, ; Jump back if not zero. > > Note the jump this translates to. > Because the assembler inverts error conditions as appropriate > this is much less error prone. > > You need a Forth mindset (and a stack) to add this to an assembler. > Outside of Forth assemblers it is rare. Not so rare. Google 'structured assembler'. A Forth-inspired add-on is here. http://dkeenan.com/AddingStructuredControlFlowToAnyAssembler.htm
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-09 02:35 -0500 |
| Message-ID | <op.xtr4pqryv6dtjm@localhost> |
| In reply to | #36394 |
On Sun, 08 Feb 2015 15:09:59 -0500, Alex McDonald <blog@rivadpm.com> wrote: > on 08/02/2015 18:21:18, hugj wrote: >> All of this assumes that the compiler is non-optimizing --- >> that it is just compiling the source-code words into >> threaded-code words one-to-one and on e-by-one --- this >> is 1970s technology. > > Can you explain how forward references are resolved in an > optimizing compiler? The same way they're resolved in a non-optimizing compiler. Did you want an actual answer or were you just trolling Hugh? ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-09 12:03 +0000 |
| Message-ID | <mba7kl$uk4$1@dont-email.me> |
| In reply to | #36407 |
on 09/02/2015 07:35:36, "Rod Pemberton" wrote: > On Sun, 08 Feb 2015 15:09:59 -0500, Alex McDonald <blog@rivadpm.com> > > wrote: >> on 08/02/2015 18:21:18, hugj wrote: > wrote: > >>> All of this assumes that the compiler is non-optimizing --- >>> that it is just compiling the source-code words into >>> threaded-code words one-to-one and on e-by-one --- this >>> is 1970s technology. >> >> Can you explain how forward references are resolved in an >> optimizing compiler? > > The same way they're resolved in a non-optimizing compiler. > > Did you want an actual answer or were you just trolling Hugh? ... > > I suspect you're right. I was tickling Hugh's stupid stick, since he seems to think from the 1980s onwards it was somehow different. > Rod Pemberton >
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-08 10:13 -0800 |
| Message-ID | <c07a6c9f-c0a2-4e08-b6c3-d9f0f7251223@googlegroups.com> |
| In reply to | #36376 |
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. This is obvious --- I think that you are just stupid --- you should really be able to understand such a simple concept: a standard has to standardize.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web