Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #40226 > unrolled thread
| Started by | hughaguilar96@gmail.com |
|---|---|
| First post | 2015-07-01 20:32 -0700 |
| Last post | 2015-07-06 01:56 -0700 |
| Articles | 20 on this page of 66 — 11 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-01 20:32 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-02 02:40 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-02 22:40 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 04:32 -0400
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-03 03:03 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-03 03:16 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-03 22:06 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-03 22:39 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 14:45 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-04 11:39 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-04 19:55 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-04 20:54 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 07:18 +0100
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-04 21:47 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 01:49 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 10:30 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 03:09 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 16:29 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 09:49 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 22:10 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 14:54 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 12:41 -1000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 15:47 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-06 00:57 +0200
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 16:08 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-06 01:36 +0200
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 17:25 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 13:15 -1000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-06 02:05 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-05 19:46 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-06 07:57 +0000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-06 18:53 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 07:37 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-08 05:18 +0000
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-08 07:59 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-08 12:06 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-08 20:08 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-09 08:31 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 14:06 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 14:09 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-09 13:34 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-10 20:27 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-10 12:46 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-10 21:48 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 17:02 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-08 17:48 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 20:58 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-08 20:19 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 21:48 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 00:47 +0100
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-09 04:56 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-11 14:34 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-07 08:09 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-07 16:32 +0200
Re: The meaning of xt in Forth-94 coos <chforth@hccnet.nl> - 2015-07-07 16:43 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 15:16 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-07 22:14 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-08 02:06 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 14:57 +0000
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-07 22:51 +0100
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-07 13:11 -1000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-07 19:34 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-06 20:47 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-06 21:55 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 08:53 -1000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-06 01:56 -0700
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-09 13:34 -0700 |
| Message-ID | <874mld83yy.fsf@jester.gateway.sonic.net> |
| In reply to | #40447 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: > Not ALLOTed. Memory is ALLOCATEd by the system for various things > amongst which is the control stack. When a control stack item is > needed it is obtained from this memory, either from a free list or > allocated from unused memory, and placed at the head of the control > stack list. When popped it is put on the free list for re-use > later. If the memory runs out another block is ALLOCATEd.... > My system is for desktop use only - not embedded systems. Aha, ok, fair enough, though you might as well use FREE when you're done with a node, instead of maintaining an application-level free list. Or you could use Anton's garbage collector. All these approaches seem more Lispy than Forthy though. And on a desktop system there's enough memory that you don't have to worry much about conservation in the amounts used for purposes like this.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-07-10 20:27 +0100 |
| Message-ID | <mnp683$njl$1@dont-email.me> |
| In reply to | #40469 |
On 09/07/2015 21:34, Paul Rubin wrote: > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: >> Not ALLOTed. Memory is ALLOCATEd by the system for various things >> amongst which is the control stack. When a control stack item is >> needed it is obtained from this memory, either from a free list or >> allocated from unused memory, and placed at the head of the control >> stack list. When popped it is put on the free list for re-use >> later. If the memory runs out another block is ALLOCATEd.... >> My system is for desktop use only - not embedded systems. > > Aha, ok, fair enough, though you might as well use FREE when you're done > with a node, instead of maintaining an application-level free list. All it costs is a call to a DELETE word that's shared with other lists Or > you could use Anton's garbage collector. All these approaches seem more > Lispy than Forthy though. And on a desktop system there's enough memory > that you don't have to worry much about conservation in the amounts used > for purposes like this. > It never occurred to me to not tidy up afterwards - unlike real life :-) -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-10 12:46 -0700 |
| Message-ID | <87egkf6biv.fsf@jester.gateway.sonic.net> |
| In reply to | #40506 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: >>> When popped it is put on the free list for re-use later. >> you might as well use FREE when you're done with a node > All it costs is a call to a DELETE word that's shared with other lists Not sure what you mean by that, but I mean you're duplicating some of the effort of ALLOCATE/FREE if you're maintaining your own free list of nodes you got from ALLOCATE and then stopped using. It's more natural to just FREE them and let ALLOCATE manage re-using the storage. >> And on a desktop system there's enough memory that you don't have to >> worry much about conservation in the amounts used for purposes like> this. > It never occurred to me to not tidy up afterwards - unlike real life :-) Well the alternative I was thinking of was just allocate a large enough stack to not need to mess with linked lists. You could grab a few thousand cells statically, or use ALLOCATE and RESIZE in the unlikely event of overflow caused by something other than a bug.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-07-10 21:48 +0100 |
| Message-ID | <mnpav3$99u$1@dont-email.me> |
| In reply to | #40507 |
On 10/07/2015 20:46, Paul Rubin wrote: > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: >>>> When popped it is put on the free list for re-use later. >>> you might as well use FREE when you're done with a node >> All it costs is a call to a DELETE word that's shared with other lists > > Not sure what you mean by that, but I mean you're duplicating some of > the effort of ALLOCATE/FREE if you're maintaining your own free list of > nodes you got from ALLOCATE and then stopped using. It's more natural > to just FREE them and let ALLOCATE manage re-using the storage. Maybe so, but my versions of ALLOCATE and FREE don't do that, it simply calls the OS. > >>> And on a desktop system there's enough memory that you don't have to >>> worry much about conservation in the amounts used for purposes like> this. >> It never occurred to me to not tidy up afterwards - unlike real life :-) > > Well the alternative I was thinking of was just allocate a large enough > stack to not need to mess with linked lists. You could grab a few > thousand cells statically, or use ALLOCATE and RESIZE in the unlikely > event of overflow caused by something other than a bug. > My background as a hardware engineer makes it hard for me to use memory wastefully - yes I know it doesn't matter these days but still ... -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-07-08 17:02 +0200 |
| Message-ID | <mnjdui$j2o$1@dont-email.me> |
| In reply to | #40412 |
Anton Ertl wrote: > Bernd Paysan has changed OF...ENDOF to use the leave stack, and this > overran the original leave stack when loading the cross compiler, > nicely demonstrating the issue with the separate stack. Or the issue with the size-limitation of the leave stack ;-). I've a generic auto-growing stack code somewhere; it probably should be used for that purpose, too. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-08 17:48 +0100 |
| Message-ID | <mnjk74$cu4$1@dont-email.me> |
| In reply to | #40419 |
on 08/07/2015 16:02:03, Bernd Paysan wrote: > Anton Ertl wrote: > >> Bernd Paysan has changed OF...ENDOF to use the leave stack, and this >> overran the original leave stack when loading the cross compiler, >> nicely demonstrating the issue with the separate stack. > > Or the issue with the size-limitation of the leave stack ;-). > > I've a generic auto-growing stack code somewhere; it probably should > be used for that purpose, too. > It's called the data stack. Only half joking.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-07-08 20:58 +0200 |
| Message-ID | <mnjrpt$jnt$2@dont-email.me> |
| In reply to | #40420 |
Alex McDonald wrote: > on 08/07/2015 16:02:03, Bernd Paysan wrote: >> Anton Ertl wrote: >> >>> Bernd Paysan has changed OF...ENDOF to use the leave stack, and this >>> overran the original leave stack when loading the cross compiler, >>> nicely demonstrating the issue with the separate stack. >> >> Or the issue with the size-limitation of the leave stack ;-). >> >> I've a generic auto-growing stack code somewhere; it probably should >> be used for that purpose, too. > > It's called the data stack. Did you understand why LEAVE can't use the data stack? -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-08 20:19 +0100 |
| Message-ID | <mnjt11$p8h$1@dont-email.me> |
| In reply to | #40423 |
on 08/07/2015 19:58:30, Bernd Paysan wrote: > Alex McDonald wrote: > >> on 08/07/2015 16:02:03, Bernd Paysan wrote: >>> Anton Ertl wrote: >>> >>>> Bernd Paysan has changed OF...ENDOF to use the leave stack, and this >>>> overran the original leave stack when loading the cross compiler, >>>> nicely demonstrating the issue with the separate stack. >>> >>> Or the issue with the size-limitation of the leave stack ;-). >>> >>> I've a generic auto-growing stack code somewhere; it probably should >>> be used for that purpose, too. >> >> It's called the data stack. > > Did you understand why LEAVE can't use the data stack? > Why not? ORIG as in the standard. do ( c: -- origD ) ?do ( c: -- ?do-sys origD ) leave ( origD [ ... ] -- orig origD [ ... ] ) \ insert orig under origD loop ( [ ?do-sys ] [ orig1 ... origN ] origD -- ) \ resolve back jmp on DO , POSTPONE THEN on orig1 thru origN and origD
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-07-08 21:48 +0200 |
| Message-ID | <mnjuo0$vna$1@dont-email.me> |
| In reply to | #40427 |
Alex McDonald wrote:
> Why not? ORIG as in the standard.
>
> do ( c: -- origD )
> ?do ( c: -- ?do-sys origD )
> leave ( origD [ ... ] -- orig origD [ ... ] ) \ insert orig under origD
> loop ( [ ?do-sys ] [ orig1 ... origN ] origD -- )
> \ resolve back jmp on DO , POSTPONE THEN on orig1 thru origN and origD
LEAVE is typically used inside a condition, such as
: scan-to-zero ( addr u -- addr' ) bounds ?DO
i c@ 0= IF ( do something ) LEAVE THEN LOOP ;
You don't even know how deep do's origD is, because for sure, more complex
control structures are allowed, too.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-09 00:47 +0100 |
| Message-ID | <mnkcoe$l99$1@dont-email.me> |
| In reply to | #40428 |
on 08/07/2015 20:48:37, Bernd Paysan wrote:
> Alex McDonald wrote:
>> Why not? ORIG as in the standard.
>>
>> do ( c: -- origD )
>> ?do ( c: -- ?do-sys origD )
>> leave ( origD [ ... ] -- orig origD [ ... ] ) \ insert orig under origD
>> loop ( [ ?do-sys ] [ orig1 ... origN ] origD -- )
>> \ resolve back jmp on DO , POSTPONE THEN on orig1 thru origN and origD
>
> LEAVE is typically used inside a condition, such as
>
>: scan-to-zero ( addr u -- addr' ) bounds ?DO
> i c@ 0= IF ( do something ) LEAVE THEN LOOP ;
>
> You don't even know how deep do's origD is, because for sure, more
> complex control structures are allowed, too.
>
If each ORIG is a tagged pair, then the following suffices. origD (aka
DO-SYS) is a pair marked MARK-DO.
: leave ( do-sys ... -- orig do-sys ... )
\ strip control stack down to do-sys
0 begin over mark-do <> while
1+ -rot 2>r
repeat >r
\ branch, put leave-sys under do-sys
postpone ahead drop mark-leave 2swap
\ restore the leave entries
r> begin ?dup while 1- 2r> rot repeat ;
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-09 04:56 +0000 |
| Message-ID | <2015Jul9.065601@mips.complang.tuwien.ac.at> |
| In reply to | #40423 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Alex McDonald wrote:
>Did you understand why LEAVE can't use the data stack?
20 cs-items are plenty for the LEAVE stack. Just not for ENDOF. So
let's use the data stack for ENDOF, like we used to (except that I
will look into making the stack effect of OF correct).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-11 14:34 -0700 |
| Message-ID | <22a62259-065a-41a7-b631-03cea7008ee1@googlegroups.com> |
| In reply to | #40443 |
On Wednesday, July 8, 2015 at 9:57:58 PM UTC-7, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > >Alex McDonald wrote: > >Did you understand why LEAVE can't use the data stack? > > 20 cs-items are plenty for the LEAVE stack. Just not for ENDOF. So > let's use the data stack for ENDOF, like we used to (except that I > will look into making the stack effect of OF correct). > > - anton When Anton says, "So let's use the data stack for ENDOF, like we used to" --- what he means is: "So let's just shut the hell up about making the control-flow stack distinct from the data-stack, because the reality is that Leon Wagner won't give us permission, and he is the owner of Forth-200x."
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-07-07 08:09 +0100 |
| Message-ID | <mnftsg$q4d$1@dont-email.me> |
| In reply to | #40350 |
On 06/07/2015 08:57, Anton Ertl wrote: > Is Eaker's CASE a sign of poor factoring? It needs one control-flow > stack item per OF. Only if you choose to implement OF and ENDOF that way e.g. as in the ANS Forth standard at the end of section A.3.2.2.2. The OF's of-syses don't have to be all kept on the data stack e.g. SwiftForth and my system don't. > And Gforth uses 3 cells per control-flow stack > item (24 bytes on a 64-bit system). Not that it matters particularly but it could be argued that GForth is not ANS compliant because the specification for ENDOF states ( C: case-sys1 of-sys -- case-sys2 ) whereas GForth seems to do ( C: case-sys1 of-sys -- of-sys case-sys1 ) e.g. try : x cr .s ; immediate : y x case x 1 of x endof x 2 of x endof x 3 of x endof x endcase ; -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-07-07 16:32 +0200 |
| Message-ID | <mngnqd$j7q$1@dont-email.me> |
| In reply to | #40388 |
Gerry Jackson wrote: > On 06/07/2015 08:57, Anton Ertl wrote: >> Is Eaker's CASE a sign of poor factoring? It needs one control-flow >> stack item per OF. > > Only if you choose to implement OF and ENDOF that way e.g. as in the ANS > Forth standard at the end of section A.3.2.2.2. The OF's of-syses don't > have to be all kept on the data stack e.g. SwiftForth and my system don't. > >> And Gforth uses 3 cells per control-flow stack >> item (24 bytes on a 64-bit system). > > Not that it matters particularly but it could be argued that GForth is > not ANS compliant because the specification for ENDOF states > ( C: case-sys1 of-sys -- case-sys2 ) whereas GForth seems to do > ( C: case-sys1 of-sys -- of-sys case-sys1 ) e.g. try > > : x cr .s ; immediate > : y x case x 1 of x endof x 2 of x endof x 3 of x endof x endcase ; It's pretty easy to fix, using LEAVE instead of ELSE to go out of the case statement. LEAVE doesn't need data on the constrol stack. One problem remains: of-sys is still 4 cells, instead of the normal 3 cells, so cs-pick or cs-roll doesn't work. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | coos <chforth@hccnet.nl> |
|---|---|
| Date | 2015-07-07 16:43 +0200 |
| Message-ID | <19lh6cubngb3.1k6ntproghx06$.dlg@40tude.net> |
| In reply to | #40401 |
Op Tue, 07 Jul 2015 16:32:01 +0200 schreef Bernd Paysan: > Gerry Jackson wrote: > >> On 06/07/2015 08:57, Anton Ertl wrote: >>> Is Eaker's CASE a sign of poor factoring? It needs one control-flow >>> stack item per OF. >> >> Only if you choose to implement OF and ENDOF that way e.g. as in the ANS >> Forth standard at the end of section A.3.2.2.2. The OF's of-syses don't >> have to be all kept on the data stack e.g. SwiftForth and my system don't. >> >>> And Gforth uses 3 cells per control-flow stack >>> item (24 bytes on a 64-bit system). >> >> Not that it matters particularly but it could be argued that GForth is >> not ANS compliant because the specification for ENDOF states >> ( C: case-sys1 of-sys -- case-sys2 ) whereas GForth seems to do >> ( C: case-sys1 of-sys -- of-sys case-sys1 ) e.g. try >> >>: x cr .s ; immediate >>: y x case x 1 of x endof x 2 of x endof x 3 of x endof x endcase ; > > It's pretty easy to fix, using LEAVE instead of ELSE to go out of the case > statement. LEAVE doesn't need data on the constrol stack. Sure, not at compile-time. But what about removing the non-existing loop-sys at run-time? > > One problem remains: of-sys is still 4 cells, instead of the normal 3 cells, > so cs-pick or cs-roll doesn't work. My do-sys, of-sys, begin-sys are all two cells because I don't allow defining locals in structures. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-07 15:16 +0000 |
| Message-ID | <2015Jul7.171623@mips.complang.tuwien.ac.at> |
| In reply to | #40401 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>It's pretty easy to fix, using LEAVE instead of ELSE to go out of the case
>statement. LEAVE doesn't need data on the constrol stack.
I guess one could also get rid of the moving of the extra stack
elements to the top that way (they just stay at the top).
>One problem remains: of-sys is still 4 cells, instead of the normal 3 cells,
>so cs-pick or cs-roll doesn't work.
Not sure why you think it has 4 cells (OF increases the stack depth by
three cells). In any case, CS-PICK and CS-ROLL only work on origs and
dests, not on of-syses or other system compilation types.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-07-07 22:14 +0200 |
| Message-ID | <mnhbsk$5c5$1@dont-email.me> |
| In reply to | #40404 |
Anton Ertl wrote: > Not sure why you think it has 4 cells (OF increases the stack depth by > three cells). It takes two cells from the case-sys or last of-sys and returns 5 cells. With the LEAVE-solution which makes n-THEN obsolete, it still takes 1 cell and returns 4 cells. The LEAVE-solution needs some rethinking, as it doesn't allow to use DO .. case .. of LEAVE endof .. endcase LOOP. > In any case, CS-PICK and CS-ROLL only work on origs and > dests, not on of-syses or other system compilation types. Still not nice. Since each CS element has a type, we could fold the THEN count into that type (do THEN for all origs until you find the case-sys), and do the special casing for Gforth's DEFAULT: extension (where ENDCASE then doesn't drop one item) by modifying the CS element's type number. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-08 02:06 +0000 |
| Message-ID | <2015Jul8.040607@mips.complang.tuwien.ac.at> |
| In reply to | #40406 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Not sure why you think it has 4 cells (OF increases the stack depth by
>> three cells).
>
>It takes two cells from the case-sys or last of-sys and returns 5 cells.
>With the LEAVE-solution which makes n-THEN obsolete, it still takes 1 cell
>and returns 4 cells.
It could just leave the one cell below the orig. That's also in
better agreement with the stack effect of OF.
That can also be done for the old approach (which left the orig on the
data stack).
>> In any case, CS-PICK and CS-ROLL only work on origs and
>> dests, not on of-syses or other system compilation types.
>
>Still not nice. Since each CS element has a type, we could fold the THEN
>count into that type (do THEN for all origs until you find the case-sys),
>and do the special casing for Gforth's DEFAULT: extension (where ENDCASE
>then doesn't drop one item) by modifying the CS element's type number.
Sounds promising.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-07 14:57 +0000 |
| Message-ID | <2015Jul7.165737@mips.complang.tuwien.ac.at> |
| In reply to | #40388 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 06/07/2015 08:57, Anton Ertl wrote:
>> Is Eaker's CASE a sign of poor factoring? It needs one control-flow
>> stack item per OF.
>
>Only if you choose to implement OF and ENDOF that way e.g. as in the ANS
>Forth standard at the end of section A.3.2.2.2. The OF's of-syses don't
>have to be all kept on the data stack e.g. SwiftForth and my system don't.
...
>Not that it matters particularly but it could be argued that GForth is
>not ANS compliant because the specification for ENDOF states
>( C: case-sys1 of-sys -- case-sys2 ) whereas GForth seems to do
>( C: case-sys1 of-sys -- of-sys case-sys1 ) e.g. try
I see no requirement that all case-syses have the same size. So what
you interpret as "of-sys case-sys1" is "case-sys2" (and the contents
are also different from the input of the ENDOF).
What is actually non-standard about Gforth's CASE as well as the CASE
presented in A.3.2.2.2 is that OF does not have the compile-time stack
effect ( -- of-sys ), but something like ( x1 x2 -- orig x1 x2 ).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-07-07 22:51 +0100 |
| Message-ID | <mnhhic$qmn$1@dont-email.me> |
| In reply to | #40403 |
On 07/07/2015 15:57, Anton Ertl wrote: >> Not that it matters particularly but it could be argued that GForth is >> >not ANS compliant because the specification for ENDOF states >> >( C: case-sys1 of-sys -- case-sys2 ) whereas GForth seems to do >> >( C: case-sys1 of-sys -- of-sys case-sys1 ) e.g. try > I see no requirement that all case-syses have the same size. So what > you interpret as "of-sys case-sys1" is "case-sys2" (and the contents > are also different from the input of the ENDOF). That's the argument I thought you would use and I wouldn't disagree. I chain the addresses as I do for multiple LEAVEs in a DO loop and ENDCASE and LOOP share code for resolving addresses. -- Gerry
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web