Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #30165 > unrolled thread
| Started by | Laurent Laborde <kerdezixe@gmail.com> |
|---|---|
| First post | 2014-05-07 13:06 -0700 |
| Last post | 2014-05-07 20:01 -0700 |
| Articles | 20 on this page of 155 — 23 participants |
Back to article view | Back to comp.lang.forth
gforth too bloated ? Laurent Laborde <kerdezixe@gmail.com> - 2014-05-07 13:06 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 13:31 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-08 00:10 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 23:21 -0700
Re: gforth too bloated ? Laurent Laborde <kerdezixe@gmail.com> - 2014-05-08 04:07 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-08 14:21 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-09 17:36 +0000
Re: gforth too bloated ? dambere@web.de - 2014-05-09 15:01 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-10 00:05 +0200
Re: gforth too bloated ? Melzzzzz <mel@zzzzz.invalid> - 2014-05-10 00:30 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 09:16 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 03:27 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-09 20:42 -0700
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-07 22:32 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 21:06 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-09 04:14 -0500
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 13:42 -0400
Re: gforth too bloated ? Roger Levy <roger.levy@gmail.com> - 2014-05-09 11:48 -0700
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 15:18 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-09 09:19 -1000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 15:30 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-09 13:21 -1000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 05:16 -0500
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 05:28 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 10:39 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 12:04 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-11 12:10 +0000
Re: gforth too bloated ? Bill Long <blongo@gmail.com> - 2014-05-11 13:11 +0000
Re: gforth too bloated ? Stan Barr <plan.b@dsl.pipex.com> - 2014-05-11 16:17 +0000
Re: gforth too bloated ? Bill Long <blongo@gmail.com> - 2014-05-11 17:10 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-11 08:34 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 22:12 +0200
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 00:38 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 00:35 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-11 23:29 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-11 23:37 -0700
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-11 23:40 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-12 00:39 -0700
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 10:20 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-12 05:10 -0700
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-13 09:17 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-13 04:28 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-12 03:19 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-13 16:40 +0000
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-13 07:56 -1000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 11:52 +0000
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-14 08:15 -1000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 16:09 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:42 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 17:21 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 10:45 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-13 12:56 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 12:03 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-14 09:17 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 16:50 +0000
Re: gforth too bloated ? AKK <akk@nospam.org> - 2014-05-14 20:26 +0200
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-14 20:38 +0200
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 20:02 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-15 14:22 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-15 17:39 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:03 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:06 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:32 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-16 02:13 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 20:18 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:08 -0500
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:28 -0500
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:23 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 07:52 -0500
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-17 09:19 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 11:51 -0500
Re: gforth too bloated ? Samuel DEVULDER <samuel-dot-devulder-at-laposte-dot-net> - 2014-05-17 22:00 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:20 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 07:54 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-16 15:51 +0200
Re: gforth too bloated ? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-16 07:59 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 13:39 +0000
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-16 01:22 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:11 -0500
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-16 15:43 +0200
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-16 01:26 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 03:42 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 13:19 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-16 17:59 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 13:20 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-18 14:08 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-18 10:07 -1000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-21 21:37 -0400
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-22 10:06 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 10:04 +0000
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-22 15:39 +0200
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-22 13:36 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 11:59 +0000
Re: gforth too bloated ? m.a.m.hendrix@tue.nl - 2014-05-20 07:11 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 14:48 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 20:27 +0000
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-22 02:23 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:51 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 13:41 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:41 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:41 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:40 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:16 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 21:09 -0400
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-15 03:57 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-15 15:50 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-15 10:07 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 16:33 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 08:04 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-17 19:03 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 04:06 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-19 01:38 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 13:38 +0000
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-20 21:39 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 15:49 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 20:30 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-17 17:59 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 04:08 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 11:07 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 11:15 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 12:11 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 12:36 +0000
Re: gforth too bloated ? m.a.m.hendrix@tue.nl - 2014-05-20 07:17 -0700
Re: gforth too bloated ? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-20 16:26 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-20 09:27 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 15:48 +0000
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 18:35 +0100
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-21 03:45 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 14:28 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-21 11:56 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-21 20:54 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 14:06 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-22 17:02 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 13:05 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-23 19:19 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 14:30 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-22 12:09 -0500
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:22 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:03 +0000
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 16:57 +0100
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-20 21:28 +0200
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 21:56 +0100
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-21 00:21 +0200
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 21:42 +0000
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-22 02:15 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:47 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 14:12 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 21:24 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 12:00 +0000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-10 13:16 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-10 11:05 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 18:11 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 02:12 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-09 16:36 +0000
Re: gforth too bloated ? jacko <jackokring@gmail.com> - 2014-05-07 20:01 -0700
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-05-16 01:26 -0700 |
| Message-ID | <6f962f2c-9eff-4cd8-890a-c8dd10cc3c2c@googlegroups.com> |
| In reply to | #30404 |
Apologies. That's http://turboforth.net/locals.html (not .htm)
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-16 03:42 -0500 |
| Message-ID | <ddGdnf52HOIUUujOnZ2dnUVZ_sCdnZ2d@supernews.com> |
| In reply to | #30404 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>
> It would also mean that the braces { } delimit the parameter list.
> I'm assuming that older, non-optimizing Forths will just define a
> temporary variable with the address location for the item on the
> stack. But, I'm not sure how older Forths would handle destroying
> or freeing the variable at the end-of-use, without major internal
> changes to the interpreter.
It's easier than you think. One simple technique is to push the
locals (plus a count) onto the return stack, then push the address of
a word that will deallocate them.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-16 13:19 +0000 |
| Message-ID | <2014May16.151900@mips.complang.tuwien.ac.at> |
| In reply to | #30404 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
[locals]
>If that understanding is correct, that's an interesting way to
>introduce optimizations which C has, such as registers, into Forth.
Stack items can be mapped to registers in Forth without need for
locals. Indeed, some Forth compilers put stack items in registers
much of the time, but not locals.
>It would also mean that the braces { } delimit the parameter list.
>I'm assuming that older, non-optimizing Forths will just define a
>temporary variable with the address location for the item on the
>stack. But, I'm not sure how older Forths would handle destroying
>or freeing the variable at the end-of-use, without major internal
>changes to the interpreter. Where is the garbage collection in an
>interpreted Forth? ...
Not sure what you mean with "older Forths", or why garbage collection
would be needed for locals, but here's how locals are compiled in
Gforth:
: test { x y } x y x y ; ok
see test
: test
>l >l @local0 @local1 @local0 @local1 lp+2 ;
>So, it still might be better to use a single Forth word instead of
>delimiters to indicate locals. Then, a definition which works on
>simple Forths might be more forthcoming. Perhaps, LOCAL within the
>colon definition could be used:
>
>: 2DUP ( x y -- x y x y ) LOCAL x LOCAL y x y x y ;
iForth has a word LOCAL. Let's see what your code does:
FORTH> 1 2 2dup .s 2drop 2drop \ original 2dup
Data: 1 2 1 2 ---
System: ---
Float: --- ok
FORTH> : 2DUP ( x y -- x y x y ) LOCAL x LOCAL y x y x y ;
Redefining 2DUP ok
FORTH> 1 2 2dup .s 2drop 2drop \ Rod Pemberton's 2dup
Data: 2 1 2 1 ---
System: ---
Float: --- ok
This demonstrates why most of us don't use LOCAL and why we prefer
{...} or {:...:}.
- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-16 17:59 -0400 |
| Message-ID | <op.xfy3dahd6zenlw@localhost> |
| In reply to | #30419 |
On Fri, 16 May 2014 09:19:00 -0400, Anton Ertl
<anton@mips.complang.tuwien.ac.at> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>> It would also mean that the braces { } delimit the parameter list.
>> I'm assuming that older, non-optimizing Forths will just define a
>> temporary variable with the address location for the item on the
>> stack. But, I'm not sure how older Forths would handle destroying
>> or freeing the variable at the end-of-use, without major internal
>> changes to the interpreter. Where is the garbage collection in an
>> interpreted Forth? ...
>
> Not sure what you mean with "older Forths", [...]
interpreted
> [...] or why garbage collection would be needed for locals, [...]
If they were created in memory, instead of being stacked, and
named, then a name collision would, result if they weren't
destroyed. Of course, since they are procedure locals, they
must be stacked to preserve the correct instance of each.
> but here's how locals are compiled in
> Gforth:
>
> : test { x y } x y x y ; ok
> see test
> : test
> >l >l @local0 @local1 @local0 @local1 lp+2 ;
>
A stack makes it easier, except that a loop is still needed to
determine the quantity of >l 's required and the stack adjustment.
Is the +2 scaled by the size of the stack items, like in C?
>> So, it still might be better to use a single Forth word instead of
>> delimiters to indicate locals. Then, a definition which works on
>> simple Forths might be more forthcoming. Perhaps, LOCAL within the
>> colon definition could be used:
>>
>> : 2DUP ( x y -- x y x y ) LOCAL x LOCAL y x y x y ;
>
> iForth has a word LOCAL. Let's see what your code does:
>
> FORTH> 1 2 2dup .s 2drop 2drop \ original 2dup
> Data: 1 2 1 2 ---
> System: ---
> Float: --- ok
> FORTH> : 2DUP ( x y -- x y x y ) LOCAL x LOCAL y x y x y ;
> Redefining 2DUP ok
> FORTH> 1 2 2dup .s 2drop 2drop \ Rod Pemberton's 2dup
> Data: 2 1 2 1 ---
> System: ---
> Float: --- ok
>
> This demonstrates why most of us don't use LOCAL and why we
> prefer {...} or {:...:}.
The reversed order is sufficient to not prefer LOCAL?
You didn't forget that this is for a RPN language did you? ;-)
Anyway, the "backwards" syntax is easily correctable.
: 2DUP ( x y -- x y x y ) LOCAL y LOCAL x x y x y ;
: 2DUP ( y x -- y x y x ) LOCAL x LOCAL y y x y x ;
Or, did I miss the point?
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-18 13:20 +0000 |
| Message-ID | <2014May18.152057@mips.complang.tuwien.ac.at> |
| In reply to | #30432 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Fri, 16 May 2014 09:19:00 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>> but here's how locals are compiled in
>> Gforth:
>>
>> : test { x y } x y x y ; ok
>> see test
>> : test
>> >l >l @local0 @local1 @local0 @local1 lp+2 ;
>>
>
>A stack makes it easier, except that a loop is still needed to
>determine the quantity of >l 's required and the stack adjustment.
>
>Is the +2 scaled by the size of the stack items, like in C?
It's just a name of a primitive. The +2 indicates that it pops two
cells off the locals stack; I won't be using a different name for the
primitive depending on cell size.
>The reversed order is sufficient to not prefer LOCAL?
Yes. There is of course the other fraction that thinks we should
strain our brains to make the job easier for the compiler, but they
tend not to use locals at all. Having locals and then expecting
programmers to reverse the definition order to just make the job
easier for the compiler is neither here nor there.
>You didn't forget that this is for a RPN language did you? ;-)
Polish notation is "- x y". Reverse polish notation is "x y -". Note
that the parameters are not reversed.
>Anyway, the "backwards" syntax is easily correctable.
>
>: 2DUP ( x y -- x y x y ) LOCAL y LOCAL x x y x y ;
>: 2DUP ( y x -- y x y x ) LOCAL x LOCAL y y x y x ;
>
>Or, did I miss the point?
You got the point that it's about the order.
However, what you missed is that, however simple you may claim the
reversal is, you got the order in this relatively simple definition
wrong on the first attempt. I prefer a notation that avoids such
pitfalls. And that's a feeling that many share, or LOCALS| with its
reversed locals would have been more popular, and "{" would have
fallen into disuse. Instead, many more people have used "{" than
LOCALS|, and "{" is now being standardized as "{:".
- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-18 14:08 -0400 |
| Message-ID | <op.xf2h0tn96zenlw@localhost> |
| In reply to | #30451 |
On Sun, 18 May 2014 09:20:57 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > However, what you missed is that, however simple you may claim the > reversal is, you got the order in this relatively simple definition > wrong on the first attempt. Not true. I was asking about why a word used to define locals wasn't used. That seemed far more reasonable to me than the braces. You chose a Forth, iForth, which happened to have a word LOCAL which worked similarly to what I was asking about and named the same as what I chose, but has a different ordering from what I posted. That doesn't get to redefine or define the order on what I posted. So, the supposedly incorrect ordering was actually "ex post facto". Admittedly, it's likely true that any LOCAL word I attempted to implement would need to work the opposite way from what I posted, since it would likely be stack based. While it may seem reasonable to you that this ordering for locals is somehow important enough to be implemented a certain way, from my perspective, it's the least important of many other things in Forth which are already backwards. I.e., it seems to make no difference that this one thing is arbitrarily deemed to be correctly ordered when so many other things were simply designed to fit or work. > Reverse polish notation is "x y -" Is that "x - y" or "y - x" ... ? Most stack operators operate against the top-of-stack as the primary data item. Subtraction in Forth is reversed from that. The point is that the order is not clear, and could be perceived as being reversed by some people, even some Forth programmers. I.e., it could be argued that subtraction in Forth should've been implemented as "y - x". So, how is the "reversed" order here any different from LOCAL? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-05-18 10:07 -1000 |
| Message-ID | <d7KdnSK_fIqUjuTOnZ2dnUVZ_tudnZ2d@supernews.com> |
| In reply to | #30453 |
On 5/18/14 8:08 AM, Rod Pemberton wrote: >> Reverse polish notation is "x y -" > > Is that "x - y" or "y - x" ... ? > > Most stack operators operate against the top-of-stack as the > primary data item. Subtraction in Forth is reversed from that. > The point is that the order is not clear, and could be perceived > as being reversed by some people, even some Forth programmers. > I.e., it could be argued that subtraction in Forth should've > been implemented as "y - x". It has always seemed to most of us easy to explain "x y -" as "just imagine moving the "-" from a postfix to an infix position." I never saw any newbies confused by that. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-05-21 21:37 -0400 |
| Message-ID | <lljkc5$7dc$1@dont-email.me> |
| In reply to | #30454 |
On 5/18/2014 4:07 PM, Elizabeth D. Rather wrote: > On 5/18/14 8:08 AM, Rod Pemberton wrote: >>> Reverse polish notation is "x y -" >> >> Is that "x - y" or "y - x" ... ? >> >> Most stack operators operate against the top-of-stack as the >> primary data item. Subtraction in Forth is reversed from that. >> The point is that the order is not clear, and could be perceived >> as being reversed by some people, even some Forth programmers. >> I.e., it could be argued that subtraction in Forth should've >> been implemented as "y - x". > > It has always seemed to most of us easy to explain "x y -" as "just > imagine moving the "-" from a postfix to an infix position." I never saw > any newbies confused by that. Oddly in the GA144 subtraction is best done the other way round, y - x. Since it has no subtract instruction the user must code it by complementing the top of stack, adding a one and then adding the two top elements. Because the carry is relatively slow this is a five instruction sequence. Or you can complement the top of stack, do the add and then complement the result saving one instruction space and time. However this implements y-x rather than x-y. But what is really spooky is that every time I have needed a subtraction it was easier to get the operands in the order of y-x than it was x-y anyway. Since the GA144 has no swap instruction this was a double benefit. Strange chip... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-05-22 10:06 +0200 |
| Message-ID | <1dsoyq1s0nn90$.15fej7nvcv6j0.dlg@40tude.net> |
| In reply to | #30551 |
Op Wed, 21 May 2014 21:37:09 -0400 schreef rickman: > On 5/18/2014 4:07 PM, Elizabeth D. Rather wrote: >> On 5/18/14 8:08 AM, Rod Pemberton wrote: >>>> Reverse polish notation is "x y -" >>> >>> Is that "x - y" or "y - x" ... ? >>> >>> Most stack operators operate against the top-of-stack as the >>> primary data item. Subtraction in Forth is reversed from that. >>> The point is that the order is not clear, and could be perceived >>> as being reversed by some people, even some Forth programmers. >>> I.e., it could be argued that subtraction in Forth should've >>> been implemented as "y - x". >> >> It has always seemed to most of us easy to explain "x y -" as "just >> imagine moving the "-" from a postfix to an infix position." I never saw >> any newbies confused by that. > > Oddly in the GA144 subtraction is best done the other way round, y - x. > Since it has no subtract instruction the user must code it by > complementing the top of stack, adding a one and then adding the two top > elements. Because the carry is relatively slow this is a five > instruction sequence. Or you can complement the top of stack, do the > add and then complement the result saving one instruction space and > time. However this implements y-x rather than x-y. But what is really > spooky is that every time I have needed a subtraction it was easier to > get the operands in the order of y-x than it was x-y anyway. Since the > GA144 has no swap instruction this was a double benefit. > > Strange chip... I don't have a GA144, but I tried a normal 2-complement Forth. Your first method: 100 70 ok invert .s ( 100 -71 ) ok 1+ .s ( 100 -70 ) ok + . 30 ok Your second method: 100 70 ok invert .s ( 100 -71 ) ok + .s ( 29 ) ok 1+ . 30 ok Both give the same and correct answer. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-22 10:04 +0000 |
| Message-ID | <2014May22.120425@mips.complang.tuwien.ac.at> |
| In reply to | #30557 |
Coos Haak <chforth@hccnet.nl> writes:
>Op Wed, 21 May 2014 21:37:09 -0400 schreef rickman:
>> Oddly in the GA144 subtraction is best done the other way round, y - x.
>> Since it has no subtract instruction the user must code it by
>> complementing the top of stack, adding a one and then adding the two top
>> elements. Because the carry is relatively slow this is a five
>> instruction sequence. Or you can complement the top of stack, do the
>> add and then complement the result saving one instruction space and
>> time. However this implements y-x rather than x-y. But what is really
>> spooky is that every time I have needed a subtraction it was easier to
>> get the operands in the order of y-x than it was x-y anyway. Since the
>> GA144 has no swap instruction this was a double benefit.
>>
>> Strange chip...
>
>I don't have a GA144, but I tried a normal 2-complement Forth.
>Your first method:
>100 70 ok
>invert .s ( 100 -71 ) ok
>1+ .s ( 100 -70 ) ok
>+ . 30 ok
>
>Your second method:
>100 70 ok
>invert .s ( 100 -71 ) ok
>+ .s ( 29 ) ok
>1+ . 30 ok
His second method is:
100 70 .s <2> 100 70 ok
invert .s <2> 100 -71 ok
+ .s <1> 29 ok
invert . -30 ok
- 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 | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-05-22 15:39 +0200 |
| Message-ID | <9aof6b811j9q.xdlnk27of0bt$.dlg@40tude.net> |
| In reply to | #30559 |
Op Thu, 22 May 2014 10:04:25 GMT schreef Anton Ertl: > Coos Haak <chforth@hccnet.nl> writes: >>Op Wed, 21 May 2014 21:37:09 -0400 schreef rickman: >>> Oddly in the GA144 subtraction is best done the other way round, y - x. >>> Since it has no subtract instruction the user must code it by >>> complementing the top of stack, adding a one and then adding the two top >>> elements. Because the carry is relatively slow this is a five >>> instruction sequence. Or you can complement the top of stack, do the >>> add and then complement the result saving one instruction space and >>> time. However this implements y-x rather than x-y. But what is really >>> spooky is that every time I have needed a subtraction it was easier to >>> get the operands in the order of y-x than it was x-y anyway. Since the >>> GA144 has no swap instruction this was a double benefit. >>> >>> Strange chip... >> >>I don't have a GA144, but I tried a normal 2-complement Forth. >>Your first method: >>100 70 ok >>invert .s ( 100 -71 ) ok >>1+ .s ( 100 -70 ) ok >>+ . 30 ok >> >>Your second method: >>100 70 ok >>invert .s ( 100 -71 ) ok >>+ .s ( 29 ) ok >>1+ . 30 ok > > His second method is: > > 100 70 .s <2> 100 70 ok > invert .s <2> 100 -71 ok > + .s <1> 29 ok > invert . -30 ok > > - anton As usual, I was hasty, you're right. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-05-22 13:36 -0400 |
| Message-ID | <lllciv$fat$1@dont-email.me> |
| In reply to | #30561 |
On 5/22/2014 9:39 AM, Coos Haak wrote: > Op Thu, 22 May 2014 10:04:25 GMT schreef Anton Ertl: > >> Coos Haak <chforth@hccnet.nl> writes: >>> Op Wed, 21 May 2014 21:37:09 -0400 schreef rickman: >>>> Oddly in the GA144 subtraction is best done the other way round, y - x. >>>> Since it has no subtract instruction the user must code it by >>>> complementing the top of stack, adding a one and then adding the two top >>>> elements. Because the carry is relatively slow this is a five >>>> instruction sequence. Or you can complement the top of stack, do the >>>> add and then complement the result saving one instruction space and >>>> time. However this implements y-x rather than x-y. But what is really >>>> spooky is that every time I have needed a subtraction it was easier to >>>> get the operands in the order of y-x than it was x-y anyway. Since the >>>> GA144 has no swap instruction this was a double benefit. >>>> >>>> Strange chip... >>> >>> I don't have a GA144, but I tried a normal 2-complement Forth. >>> Your first method: >>> 100 70 ok >>> invert .s ( 100 -71 ) ok >>> 1+ .s ( 100 -70 ) ok >>> + . 30 ok >>> >>> Your second method: >>> 100 70 ok >>> invert .s ( 100 -71 ) ok >>> + .s ( 29 ) ok >>> 1+ . 30 ok >> >> His second method is: >> >> 100 70 .s <2> 100 70 ok >> invert .s <2> 100 -71 ok >> + .s <1> 29 ok >> invert . -30 ok >> >> - anton > > As usual, I was hasty, you're right. I think I am missing the point of any of this. I'm also not clear on what *my* first and second approaches are... I guess you mean the conventional way of forming a two's complement of the TOS and adding vs the method that is shorter on the GA144 of complementing the TOS, then adding and complementing the result. Both perform subtraction, but the second method reverses the operands equivalent to SWAP - in forth. I got this from reading Chuck's blog and programming notes on the GA144. It is a shame that the chip is so limited in so many ways other than the CPU design. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-20 11:59 +0000 |
| Message-ID | <2014May20.135936@mips.complang.tuwien.ac.at> |
| In reply to | #30453 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Sun, 18 May 2014 09:20:57 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>
>> However, what you missed is that, however simple you may claim the
>> reversal is, you got the order in this relatively simple definition
>> wrong on the first attempt.
>
>Not true.
>
>I was asking about why a word used to define locals wasn't used.
>That seemed far more reasonable to me than the braces.
>
>You chose a Forth, iForth, which happened to have a word LOCAL
>which worked similarly to what I was asking about and named the
>same as what I chose, but has a different ordering from what I
>posted. That doesn't get to redefine or define the order on
>what I posted.
>
>So, the supposedly incorrect ordering was actually "ex post facto".
Name one Forth system that has LOCAL, where the first version of your
2DUP works!
The word LOCAL has been discussed here several times, always with the
meaning implemented in iForth. Why do you claim you had a different
meaning in mind, and if so, why did you not explain that meaning when
you posted the code, nor when I first pointed out the mistake
(instead, you posted two versions of the code that would work with
iForth). It seems that you are changing the goalposts, not me.
So how would you specify your LOCAL with { ... } like ordering, and
how would it be implemented?
>> Reverse polish notation is "x y -"
>
>Is that "x - y" or "y - x" ... ?
x-y in infix is x y - in postfix.
>Most stack operators operate against the top-of-stack as the
>primary data item. Subtraction in Forth is reversed from that.
>The point is that the order is not clear, and could be perceived
>as being reversed by some people, even some Forth programmers.
>I.e., it could be argued that subtraction in Forth should've
>been implemented as "y - x".
>
>So, how is the "reversed" order here any different from LOCAL?
Are you really arguing that subtraction in Forth should have reversed
arguments (without giving a reason for that) in order to justify that
the error-prone LOCAL is "better" than { ... } ?
Reality check: The ordering of - arguments is not reversed, and the
iForth LOCAL is error-prone, as evidenced by your first implementation
of 2DUP with LOCAL.
- 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 | m.a.m.hendrix@tue.nl |
|---|---|
| Date | 2014-05-20 07:11 -0700 |
| Message-ID | <80827471-15e9-4b2d-aa1b-4cc4f3b4d91e@googlegroups.com> |
| In reply to | #30471 |
On Tuesday, May 20, 2014 1:59:36 PM UTC+2, Anton Ertl wrote: [..] > Reality check: [..deleted..], and the > iForth LOCAL is error-prone, as evidenced by your first implementation > of 2DUP with LOCAL. A real Forth person will not make errors with ( n -- ) LOCAL a, as it obvious that a is initialized from TOS. Your loathing of LOCALS| is well known, and for LOCALS| it is indeed unclear in what order arguments will be initialized. However, that problem does not (cannot) occur with LOCAL. Hence, I remain puzzled by your obvious irritation (unless caused by attempting to mud-wrestle pigs). -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-20 14:48 +0000 |
| Message-ID | <2014May20.164810@mips.complang.tuwien.ac.at> |
| In reply to | #30475 |
m.a.m.hendrix@tue.nl writes:
>On Tuesday, May 20, 2014 1:59:36 PM UTC+2, Anton Ertl wrote:
>[..]=20
>> Reality check: [..deleted..], and the
>> iForth LOCAL is error-prone, as evidenced by your first implementation
>> of 2DUP with LOCAL.
>
>A real Forth person will not make errors with ( n -- ) LOCAL a, as it=20
>obvious that a is initialized from TOS.=20
Maybe not in such a simple definition as 2DUP, but in a more demanding
one, I expect more errors than with {: ... :}. If you have to
concentrate on both reversing the order of locals and whatever else is
going on in the word, there is an increased chance that you will
overlook something.
>Your loathing of LOCALS| is well known, and for LOCALS| it is indeed unclea=
>r in what order arguments will be initialized. However, that problem does n=
>ot (cannot) occur with LOCAL.
The order of locals is specified clearly in the specification of
LOCALS|. That's not the problem with LOCALS|. The problem is that
the order of locals in LOCALS| is wrong.
- 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-05-21 20:27 +0000 |
| Message-ID | <537d0c32$0$27125$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #30480 |
In article <2014May20.164810@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>m.a.m.hendrix@tue.nl writes:
>>On Tuesday, May 20, 2014 1:59:36 PM UTC+2, Anton Ertl wrote:
>>[..]=20
>>> Reality check: [..deleted..], and the
>>> iForth LOCAL is error-prone, as evidenced by your first implementation
>>> of 2DUP with LOCAL.
>>
>>A real Forth person will not make errors with ( n -- ) LOCAL a, as it=20
>>obvious that a is initialized from TOS.=20
>
>Maybe not in such a simple definition as 2DUP, but in a more demanding
>one, I expect more errors than with {: ... :}. If you have to
>concentrate on both reversing the order of locals and whatever else is
>going on in the word, there is an increased chance that you will
>overlook something.
I've used the LOCAL syntax extensively in the time I cooperated with Marcel
on tForth. (We had the MPQS sieve factoring method implemented in transputers.)
By initializing from the stack *one by one* there is no confusion and I didn't
find it hard to use at all. The confusion started with the systems that
initialize more than one local at the same time, which leads IMO to a non-Forth
like syntax and very contorted descriptions of how they work.
There is an other advantage to LOCAL that Marcel didn't mention. You can
perform operations before you initialize the next local as in
... LOCAL N S>D D>F 1000e F/ FSIN 1000e0 F* F>D D>S LOCAL fixed-point-sin ...
All in all I find LOCAL FLOCAL DLOCAL the least objectional incarnation of the
locals concept.
At the time it made me choose practicality over purity.
(In number theory there are a lot of variables, and we had to convert code
from UBASIC.)
>
>>Your loathing of LOCALS| is well known, and for LOCALS| it is indeed unclea=
>>r in what order arguments will be initialized. However, that problem does n=
>>ot (cannot) occur with LOCAL.
>
>The order of locals is specified clearly in the specification of
>LOCALS|. That's not the problem with LOCALS|. The problem is that
>the order of locals in LOCALS| is wrong.
LOCALS| would drive me nuts. It is not the order. It is the necessity to
have all the locals prepared at the same time.
>
>- anton
>--
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-05-22 02:23 -0700 |
| Message-ID | <00efcd3a-e76a-439b-93b7-3e6f490e6d0f@googlegroups.com> |
| In reply to | #30532 |
I ended using LOCALS{ a b c } to declare locals named a b and c. However, they are NOT initialised from the stack at all. That's because they're local *variables* not local representations of what was on the stack. Maybe I want the stuff on the stack to stay on the stack after the word completes? Maybe I want the locals for internal loop counters and not to represent data that is on the stack. By not initialising my locals from the stack, I can literally do anything I want with them.
If I want to load them from the stack, I can, with SET and +SET. Silly example:
: foo ( a b c -- a+b+c )
locals{ x y z sum }
SET z \ c to z
SET y \ b to y
SET x \ a to x
x y + z + set sum
sum ;
(dumb example, just to illustrate the point)
I really like it. I'm very comfortable with it.
"When you've seen one Forth, you've seen one Forth." :-)
MPE has a REALLY good system going for it's locals, with it's named inputs and named outputs.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-23 14:51 +0000 |
| Message-ID | <2014May23.165100@mips.complang.tuwien.ac.at> |
| In reply to | #30558 |
Mark Wills <markwills1970@gmail.com> writes:
>Maybe I wa=
>nt the stuff on the stack to stay on the stack after the word completes?
That's the case for anything locals-like I have heard about in the
last 20 years.
> Ma=
>ybe I want the locals for internal loop counters and not to represent data =
>that is on the stack.
How do you get the loop counters into the locals without going through
the data stack?
>MPE has a REALLY good system going for it's locals, with it's named inputs =
>and named outputs.=20
Named outputs? Please elaborate.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-23 13:41 +0000 |
| Message-ID | <2014May23.154123@mips.complang.tuwien.ac.at> |
| In reply to | #30532 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2014May20.164810@mips.complang.tuwien.ac.at>,
>>Maybe not in such a simple definition as 2DUP, but in a more demanding
>>one, I expect more errors than with {: ... :}. If you have to
>>concentrate on both reversing the order of locals and whatever else is
>>going on in the word, there is an increased chance that you will
>>overlook something.
>
>I've used the LOCAL syntax extensively in the time I cooperated with Marcel
>on tForth. (We had the MPQS sieve factoring method implemented in transputers.)
>
>By initializing from the stack *one by one* there is no confusion and I didn't
>find it hard to use at all.
There is no confusion of what LOCALS| a x | or LOCAL a LOCAL x means.
The issue is just that they require reversing the order of locals
declaratiion from what my mential picture of the stack is; which is:
TOS is rightmost, as in stack pictures and stack effect comments.
Why is it that way? Because, when we write
1 2 3
the rightmost value (3) is the TOS.
You might argue that when you do
. . .
the TOS is printed leftmost. That's true, but it seems to me that the
input order is more often an issue than the output order. Apart from
stack manipulation words, most words only have zero or one output, and
for those that have more outputs, the usage is often highly stylized,
so it does not matter: E.g., words that produce an ior produce it on
the TOS, and at least in my code such words are nearly always followed
by THROW, so I don't need to think about the stack order if the ior.
So, input order is much more often an issue than output order, that's
why we put the TOS rightmost in stack comments, and that's why many of
us put the local to be initialized from the TOS rightmost in local
definitions.
>The confusion started with the systems that
>initialize more than one local at the same time, which leads IMO to a non-Forth
>like syntax and very contorted descriptions of how they work.
Purists don't use locals at all, so a Forth-purity argument is trumped
by usability.
>There is an other advantage to LOCAL that Marcel didn't mention. You can
>perform operations before you initialize the next local as in
> ... LOCAL N S>D D>F 1000e F/ FSIN 1000e0 F* F>D D>S LOCAL fixed-point-sin ...
{: N :} S>D D>F 1000e F/ FSIN 1000e0 F* F>D D>S {: fixed-point-sin :}
>LOCALS| would drive me nuts. It is not the order. It is the necessity to
>have all the locals prepared at the same time.
That's a restriction that high-quality systems do not have. LOCALS|
are still a bad idea, because of the order.
- 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 | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-21 17:41 -0400 |
| Message-ID | <op.xf8bvriw6zenlw@localhost> |
| In reply to | #30480 |
On Tue, 20 May 2014 10:48:10 -0400, Anton Ertl
<anton@mips.complang.tuwien.ac.at> wrote:
> m.a.m.hendrix@tue.nl writes:
>> A real Forth person will not make errors with ( n -- ) LOCAL a, as it=20
>> obvious that a is initialized from TOS.=20
>
> Maybe not in such a simple definition as 2DUP, but in a more demanding
> one, I expect more errors than with {: ... :}. If you have to
> concentrate on both reversing the order of locals and whatever else is
> going on in the word, there is an increased chance that you will
> overlook something.
>
You already have to reverse the order in Forth. The stack image in
Forth is expressed in reverse order: ( a b c -- ) The c itme is on
the top of the stack.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web