Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #38115 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2015-04-11 01:16 -0700 |
| Last post | 2015-04-30 02:35 -0700 |
| Articles | 20 on this page of 169 — 23 participants |
Back to article view | Back to comp.lang.forth
How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-11 01:16 -0700
Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-11 15:56 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-11 15:48 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-11 17:43 -0700
Re: How efficient are locals? How portable? "HAA" <someone@microsoft.com> - 2015-04-14 18:40 +1000
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 19:23 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 13:28 -0700
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 22:29 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 16:01 -0700
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 23:20 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 00:28 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 02:30 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 09:57 +0000
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-23 11:28 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-23 09:31 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 13:32 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 10:56 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 11:12 -0700
Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-23 22:44 +0200
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 23:24 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 09:21 +0000
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-24 11:44 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-24 08:35 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 15:40 +0000
Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-24 10:28 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 17:43 +0000
Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-24 22:44 -0700
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-24 15:00 +0000
Re: How efficient are locals? How portable? Paul Rubin <no.email@nospam.invalid> - 2015-04-24 09:07 -0700
Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-23 07:30 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-23 11:02 -0400
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-23 16:30 +0100
Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-23 09:38 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 15:57 +0100
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-24 15:14 +0000
Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-23 06:58 -0400
Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-23 14:47 +0200
Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-23 08:34 -1000
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-13 12:32 +0000
Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-13 21:57 -0400
Re: How efficient are locals? How portable? Paul Rubin <no.email@nospam.invalid> - 2015-04-13 19:25 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 01:43 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 01:45 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-14 10:12 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 13:09 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-15 14:18 -0700
Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-15 22:13 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-15 23:14 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-16 01:12 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-16 01:23 -0700
Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-16 14:28 -0400
Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-16 14:37 -0400
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-17 04:43 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-14 14:53 +0000
Re: How efficient are locals? How portable? Julian Fondren <julian.fondren@gmail.com> - 2015-04-16 00:34 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-16 00:54 -0700
Re: How efficient are locals? How portable? Julian Fondren <julian.fondren@gmail.com> - 2015-04-16 01:07 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 12:22 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-16 08:32 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-16 20:42 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-17 00:14 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-16 22:14 -0700
Re: How efficient are locals? How portable? Bernd Linsel <bl1@gmx.com> - 2015-04-17 17:43 +0200
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:46 +0000
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 06:54 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-18 06:52 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-18 22:14 -0700
Re: How efficient are locals? How portable? "WJ" <w_a_x_man@yahoo.com> - 2015-04-19 08:46 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 06:04 -0400
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-19 10:12 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 10:43 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 16:28 -0400
Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-19 15:35 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 19:14 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 16:48 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 09:51 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-20 06:27 -0400
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-20 13:04 +0000
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 14:09 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 07:17 -0400
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-21 16:50 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 16:35 -0400
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:13 -0400
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:23 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-21 17:18 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 16:38 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 10:12 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:26 -0400
Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-20 08:46 -1000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 23:02 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 06:35 -0400
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 06:41 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 10:22 +0000
Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-20 23:28 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-21 11:03 +0000
Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-21 07:20 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 15:35 +0000
Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-23 10:55 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 07:15 +0000
Re: How efficient are locals? How portable? Bernd Linsel <bl1@gmx.com> - 2015-04-20 17:52 +0200
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 09:03 -0700
Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 08:33 +0200
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 02:20 -0700
Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 11:35 +0200
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-20 17:50 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-17 01:45 -0700
Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-17 02:37 -0700
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:14 +0000
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 10:18 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-17 09:38 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-17 21:25 +0100
Re: How efficient are locals? How portable? "WJ" <w_a_x_man@yahoo.com> - 2015-04-18 07:51 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 08:45 -0700
Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-19 16:24 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 09:58 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-19 19:00 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 12:27 -0700
Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-19 19:42 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 13:49 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 09:39 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 17:59 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 16:39 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-20 04:58 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 08:52 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-20 18:04 +0100
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-20 19:05 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-24 10:06 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 19:18 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-24 11:43 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 22:03 +0100
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-26 20:05 +0100
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-26 21:05 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-26 15:08 -0700
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 00:17 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-27 03:55 -0400
Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-26 22:25 -1000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-29 08:53 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-29 09:35 -0700
Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-29 10:14 -0700
Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-29 09:00 -1000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-29 13:22 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-05-10 22:50 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-05-10 22:53 -0700
Re: How efficient are locals? How portable? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-26 23:04 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-26 20:51 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:38 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-27 23:18 -0700
Re: How efficient are locals? How portable? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-28 03:19 -0400
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 12:33 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-27 23:31 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-28 08:07 +0100
Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-28 10:20 +0200
Re: How efficient are locals? How portable? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-28 12:17 +0100
Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-28 14:04 +0200
Re: How efficient are locals? How portable? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-28 14:49 +0100
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-28 22:56 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 23:22 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-17 13:44 -0700
Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-18 00:31 +0200
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:22 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-18 22:51 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-19 01:25 -0700
Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-19 21:12 +0200
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-19 12:56 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 17:53 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 11:59 +0000
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 00:33 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 08:31 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-30 02:35 -0700
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-04-13 19:25 -0700 |
| Message-ID | <87ioczzbrx.fsf@jester.gateway.sonic.net> |
| In reply to | #38179 |
rickman <gnuarm@gmail.com> writes: > For those less familiar with the internals of how locals work could > someone give me the nickel tour? > I would have thought they could be addressed while on the stack, but I > suppose they would be in the way of normal use of the stack. ... > So how dem do dat? Gforth puts them on a separate locals stack, so they can have multiple types of data such as floating point. Some other implementations put them in the return stack. In both cases there's the need to clean up when the function exits.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-14 01:43 -0700 |
| Message-ID | <49f42008-cbf4-4c2c-9d0e-9c1062840aea@googlegroups.com> |
| In reply to | #38179 |
On Tuesday, 14 April 2015 02:57:06 UTC+1, rickman wrote:
> On 4/13/2015 8:32 AM, Anton Ertl wrote:
> > lehs <> writes:
> >> I really, really like to use local variables. But not to the price of low efficiency and portability. What is the price?
> >>
> >> And if it is possible to make it run fast, shouldn't there be a standard?
> >
> > Locals are standardized in Forth-94 and Forth-2012, and they are
> > portable between systems.
> >
> > It is possible to make them fast, but some systems fail to do so yet.
> > This is somewhat of a chicken-and-egg problem: There is not that much
> > code that uses locals, yet, so system implementors have little
> > incentive to make them fast, so people avoid locals for
> > performance-critical code. As a result, there is not that much code
> > that uses locals, yet.
>
> For those less familiar with the internals of how locals work could
> someone give me the nickel tour?
>
> I would have thought they could be addressed while on the stack, but I
> suppose they would be in the way of normal use of the stack. So they
> must be pulled off and stored somewhere. I suppose space is allocated
> in the dictionary without a header. But if something else is allocated
> while the local is in use, that space could not be freed up when the
> local scope is exited.
>
> So how dem do dat?
>
> --
>
> Rick
There's some background on my implementation here:
http://turboforth.net/locals.html
It's not a standard implementation, in so far as the locals
don't automatically get loaded from values from the stack.
I took the view that maybe I want to leave some values on the
stack, perhaps I don't need them to be locals. Other values
I might want to load into locals. In that case, I explicitly
set them using the word SET.
For a (fictional) example, perhaps I've got serial port parameters
stored in a structure. My OpenSerialPort word takes an address
of the structure. From there, I can extract the serial port
parameters from the structure, and (for example) sanity check
them before attempting to open a serial port.
: OpenSerialPort ( structaddr -- flag )
locals{ struct baudRate parity startBit stopBit }
set struct \ structaddr to struct (address of struct)
struct @ set baudRate
struct 1 cells + @ set parity
struct 2 cells + @ set startBit
struct 3 cells + @ set stopBit
baudRate 1200 19200 within if
.. .. ..
else
true abort" Invalid baudrate"
then
..
..
..
;
The mechanics of how it's implemented are described at the above
link. Again, I'm afraid it's non standard. Other systems that I
looked at make temporary entries in the dictionary (which would
have to be cleaned up after a definition is compiled.) which
seemed messy to me. I chose to hash the names of the locals in
a table at the end of memory. The locals' names are hashed and
stored in the table in the order in which they are encountered
in the LOCALS{ } definition. Thus, there is an ordinal relationship
between their position in the table, and their eventual offsets
into the locals stack at runtime. In otherwords, the 3rd local
in the table will be the 3rd local in the locals stack at run
time.
When a new definition (containing locals) is compiled, the same
area of memroy is used for a new table.
At runtime, a definition that uses locals has the following
compiled into it automatically:
(allotLocals) ( n - ) allots n cells of locals stack space. This is
compiled into the definition at the start (immediately after DOCOL;
note my system is a classical ITC system) by LOCALS{
(freeLocals) ( n - ) compiled into a (locals containing) definition
by ; frees up n cells of space on the return stack.
Referencing locals is simple. There's little overhead: SET <name>
looks up the position of the of the local on the return stack
and compiles a call to (SET). This is done at compile time.
Fetching is the same, just compiles a call to @local.
On my system, FIND is extended. I allow the normal FIND to run
FIRST. If the word in question is not found, I hash the word and
search the locals table. If found, a reference is compiled,
otherwise a standard "not found" error is given.
Works well. I'm personally a fan of locals. I think they make
the code easier to understand.
HTH
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-14 01:45 -0700 |
| Message-ID | <8866683c-3975-4d52-85e6-847e13fae43d@googlegroups.com> |
| In reply to | #38182 |
On Tuesday, 14 April 2015 09:43:43 UTC+1, Mark Wills wrote:
> On Tuesday, 14 April 2015 02:57:06 UTC+1, rickman wrote:
> > On 4/13/2015 8:32 AM, Anton Ertl wrote:
> > > lehs <> writes:
> > >> I really, really like to use local variables. But not to the price of low efficiency and portability. What is the price?
> > >>
> > >> And if it is possible to make it run fast, shouldn't there be a standard?
> > >
> > > Locals are standardized in Forth-94 and Forth-2012, and they are
> > > portable between systems.
> > >
> > > It is possible to make them fast, but some systems fail to do so yet.
> > > This is somewhat of a chicken-and-egg problem: There is not that much
> > > code that uses locals, yet, so system implementors have little
> > > incentive to make them fast, so people avoid locals for
> > > performance-critical code. As a result, there is not that much code
> > > that uses locals, yet.
> >
> > For those less familiar with the internals of how locals work could
> > someone give me the nickel tour?
> >
> > I would have thought they could be addressed while on the stack, but I
> > suppose they would be in the way of normal use of the stack. So they
> > must be pulled off and stored somewhere. I suppose space is allocated
> > in the dictionary without a header. But if something else is allocated
> > while the local is in use, that space could not be freed up when the
> > local scope is exited.
> >
> > So how dem do dat?
> >
> > --
> >
> > Rick
>
> There's some background on my implementation here:
>
> http://turboforth.net/locals.html
>
> It's not a standard implementation, in so far as the locals
> don't automatically get loaded from values from the stack.
> I took the view that maybe I want to leave some values on the
> stack, perhaps I don't need them to be locals. Other values
> I might want to load into locals. In that case, I explicitly
> set them using the word SET.
>
> For a (fictional) example, perhaps I've got serial port parameters
> stored in a structure. My OpenSerialPort word takes an address
> of the structure. From there, I can extract the serial port
> parameters from the structure, and (for example) sanity check
> them before attempting to open a serial port.
>
> : OpenSerialPort ( structaddr -- flag )
> locals{ struct baudRate parity startBit stopBit }
> set struct \ structaddr to struct (address of struct)
> struct @ set baudRate
> struct 1 cells + @ set parity
> struct 2 cells + @ set startBit
> struct 3 cells + @ set stopBit
> baudRate 1200 19200 within if
> .. .. ..
> else
> true abort" Invalid baudrate"
> then
> ..
> ..
> ..
> ;
>
> The mechanics of how it's implemented are described at the above
> link. Again, I'm afraid it's non standard. Other systems that I
> looked at make temporary entries in the dictionary (which would
> have to be cleaned up after a definition is compiled.) which
> seemed messy to me. I chose to hash the names of the locals in
> a table at the end of memory. The locals' names are hashed and
> stored in the table in the order in which they are encountered
> in the LOCALS{ } definition. Thus, there is an ordinal relationship
> between their position in the table, and their eventual offsets
> into the locals stack at runtime. In otherwords, the 3rd local
> in the table will be the 3rd local in the locals stack at run
> time.
>
> When a new definition (containing locals) is compiled, the same
> area of memroy is used for a new table.
>
> At runtime, a definition that uses locals has the following
> compiled into it automatically:
>
> (allotLocals) ( n - ) allots n cells of locals stack space. This is
> compiled into the definition at the start (immediately after DOCOL;
> note my system is a classical ITC system) by LOCALS{
>
> (freeLocals) ( n - ) compiled into a (locals containing) definition
> by ; frees up n cells of space on the return stack.
>
> Referencing locals is simple. There's little overhead: SET <name>
> looks up the position of the of the local on the return stack
> and compiles a call to (SET). This is done at compile time.
> Fetching is the same, just compiles a call to @local.
>
> On my system, FIND is extended. I allow the normal FIND to run
> FIRST. If the word in question is not found, I hash the word and
> search the locals table. If found, a reference is compiled,
> otherwise a standard "not found" error is given.
>
> Works well. I'm personally a fan of locals. I think they make
> the code easier to understand.
>
> HTH
I should add that the inclusion of a separate locals stack means
that you can use the return stack for your own use, even when locals
are in play. Some other systems (VFX) use the return stack for locals
but still allow the use of the return stack (>R and R>) by (presumably)
tracking the difference in the depth of the return stack.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-14 10:12 -0700 |
| Message-ID | <1d469e70-a025-436e-b977-a4f7d0e31542@googlegroups.com> |
| In reply to | #38183 |
On Tuesday, April 14, 2015 at 1:45:58 AM UTC-7, Mark Wills wrote: > I should add that the inclusion of a separate locals stack means > that you can use the return stack for your own use, even when locals > are in play. Some other systems (VFX) use the return stack for locals > but still allow the use of the return stack (>R and R>) by (presumably) > tracking the difference in the depth of the return stack. You don't need to track how many >R data are on the return-stack --- also, this is impossible at compile-time because >R may be inside of a loop. All you need to do is dedicate a register as a local-frame pointer. First you push the old local-frame pointer to the return-stack. Then you make room for your locals on the return-stack. Then you copy the return-stack pointer into the local-frame pointer. After that you can use >R as much as you want, and this doesn't affect the local-frame pointer. A side benefit, is that you don't need to match R> with >R --- you can have >R data on the return-stack when EXIT exits the function. EXIT will copy the local-frame pointer to the return-stack pointer, remove all the local variables from the return-stack, and pop the old local-frame pointer from the return stack into the local-frame pointer. Then do a return-from-subroutine to get back to the calling function. I haven't studied VFX, but afaik that is what it does. I do something similar in my language, but slightly more complicated because I have quotations in which case I extract the new local-frame pointer from the xt (this is the local-frame pointer for the parent function, that is still in scope).
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-14 13:09 -0700 |
| Message-ID | <387d5b96-972a-443d-a6bc-25a423618b2a@googlegroups.com> |
| In reply to | #38189 |
That's great info. Thanks Hugh.
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-15 14:18 -0700 |
| Message-ID | <4840e597-087e-4a8a-8ea1-ca41481f1ce7@googlegroups.com> |
| In reply to | #38182 |
Den tisdag 14 april 2015 kl. 10:43:43 UTC+2 skrev Mark Wills:
> On Tuesday, 14 April 2015 02:57:06 UTC+1, rickman wrote:
> > On 4/13/2015 8:32 AM, Anton Ertl wrote:
> > > lehs <> writes:
> > >> I really, really like to use local variables. But not to the price of low efficiency and portability. What is the price?
> > >>
> > >> And if it is possible to make it run fast, shouldn't there be a standard?
> > >
> > > Locals are standardized in Forth-94 and Forth-2012, and they are
> > > portable between systems.
> > >
> > > It is possible to make them fast, but some systems fail to do so yet.
> > > This is somewhat of a chicken-and-egg problem: There is not that much
> > > code that uses locals, yet, so system implementors have little
> > > incentive to make them fast, so people avoid locals for
> > > performance-critical code. As a result, there is not that much code
> > > that uses locals, yet.
> >
> > For those less familiar with the internals of how locals work could
> > someone give me the nickel tour?
> >
> > I would have thought they could be addressed while on the stack, but I
> > suppose they would be in the way of normal use of the stack. So they
> > must be pulled off and stored somewhere. I suppose space is allocated
> > in the dictionary without a header. But if something else is allocated
> > while the local is in use, that space could not be freed up when the
> > local scope is exited.
> >
> > So how dem do dat?
> >
> > --
> >
> > Rick
>
> There's some background on my implementation here:
>
> http://turboforth.net/locals.html
>
> It's not a standard implementation, in so far as the locals
> don't automatically get loaded from values from the stack.
> I took the view that maybe I want to leave some values on the
> stack, perhaps I don't need them to be locals. Other values
> I might want to load into locals. In that case, I explicitly
> set them using the word SET.
>
> For a (fictional) example, perhaps I've got serial port parameters
> stored in a structure. My OpenSerialPort word takes an address
> of the structure. From there, I can extract the serial port
> parameters from the structure, and (for example) sanity check
> them before attempting to open a serial port.
>
> : OpenSerialPort ( structaddr -- flag )
> locals{ struct baudRate parity startBit stopBit }
> set struct \ structaddr to struct (address of struct)
> struct @ set baudRate
> struct 1 cells + @ set parity
> struct 2 cells + @ set startBit
> struct 3 cells + @ set stopBit
> baudRate 1200 19200 within if
> .. .. ..
> else
> true abort" Invalid baudrate"
> then
> ..
> ..
> ..
> ;
>
> The mechanics of how it's implemented are described at the above
> link. Again, I'm afraid it's non standard. Other systems that I
> looked at make temporary entries in the dictionary (which would
> have to be cleaned up after a definition is compiled.) which
> seemed messy to me. I chose to hash the names of the locals in
> a table at the end of memory. The locals' names are hashed and
> stored in the table in the order in which they are encountered
> in the LOCALS{ } definition. Thus, there is an ordinal relationship
> between their position in the table, and their eventual offsets
> into the locals stack at runtime. In otherwords, the 3rd local
> in the table will be the 3rd local in the locals stack at run
> time.
>
> When a new definition (containing locals) is compiled, the same
> area of memroy is used for a new table.
>
> At runtime, a definition that uses locals has the following
> compiled into it automatically:
>
> (allotLocals) ( n - ) allots n cells of locals stack space. This is
> compiled into the definition at the start (immediately after DOCOL;
> note my system is a classical ITC system) by LOCALS{
>
> (freeLocals) ( n - ) compiled into a (locals containing) definition
> by ; frees up n cells of space on the return stack.
>
> Referencing locals is simple. There's little overhead: SET <name>
> looks up the position of the of the local on the return stack
> and compiles a call to (SET). This is done at compile time.
> Fetching is the same, just compiles a call to @local.
>
> On my system, FIND is extended. I allow the normal FIND to run
> FIRST. If the word in question is not found, I hash the word and
> search the locals table. If found, a reference is compiled,
> otherwise a standard "not found" error is given.
>
> Works well. I'm personally a fan of locals. I think they make
> the code easier to understand.
>
> HTH
Those locals would facilitate for c-programmers to use Forth. How efficient is it?
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-04-15 22:13 -0700 |
| Message-ID | <3a596edd-56fe-4d0d-92cf-a4055cf18c40@googlegroups.com> |
| In reply to | #38208 |
> Those locals would facilitate for c-programmers to use Forth. How efficient is it? How efficient compared to what? Locals help everybody, including forth programmers :)
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-15 23:14 -0700 |
| Message-ID | <6c5070a1-1480-4145-8edd-a1caa89b9a37@googlegroups.com> |
| In reply to | #38211 |
Den torsdag 16 april 2015 kl. 07:13:12 UTC+2 skrev Raimond Dragomir: > > Those locals would facilitate for c-programmers to use Forth. How efficient is it? > > How efficient compared to what? > Locals help everybody, including forth programmers :) Yes, they increases my efficiency when making programs a lot, but how fast is the code compared with code from ordinary Forth programming?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-16 01:12 -0700 |
| Message-ID | <e4f6a038-6fab-4a30-bcdf-af9cf9a8ac79@googlegroups.com> |
| In reply to | #38208 |
On Wednesday, 15 April 2015 22:18:58 UTC+1, lehs wrote:
> Those locals would facilitate for c-programmers to use Forth. How efficient is it?
Hi Lehs
I would say they are "quite efficient". Basically, at runtime, your locals are loaded into an array. Reading and writing from/to the locals is a case of taking the base address of the locals (i.e. the address of the top of the locals stack), adding an offset, and performing the read or write.
The following code:
: TEST ( -- )
LOCALS{ n }
99 set n
n .
;
Produces the following code:
DOCOL \ standard forth word nest
1 (allotLocals) \ reserve space for 1 local on the locals stack
99 0 (set) \ write 99 to the first local (n)
0 @local \ fetch it back (it's now on the stack)
dot \ display it
1 (freeLocals) \ clean up locals stack
exit \ return to calling word
So, you can see, for a colon def that contains a local(s), there
is a call to (allotLocals) and (freeLocals), and other than that
there is just the call to (set) and @local as you read and write
your locals.
In my implementation, (set) and @local are written in high-level
Forth. They are simply:
: (SET) ( value offset -- )
\ at runtime, set a local variable to to value value
_LS + ! ;
: @local ( index -- n )
\ fetch a local from the local stack
_LS + @ ;
These are of course excellent candidates for hand-writing in
assembler (on non-optimising systems such as mine). But I would
say in systems such as VFX and Swift, Mecrisp etc there would be
no need. They compile optimised native machine code, so they are
better left as high-level code. Note though that those systems
(at least VFX and Swift) already support locals, but not my
non-standard, home-grown variant, obviously.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-16 01:23 -0700 |
| Message-ID | <25f0e25d-927d-4071-bdbb-af5bf1319a41@googlegroups.com> |
| In reply to | #38217 |
On Thursday, 16 April 2015 09:12:42 UTC+1, Mark Wills wrote: > I would say they are "quite efficient". Basically, at runtime, your locals are loaded into an array. Reading and writing from/to the locals is a case of taking the base address of the locals (i.e. the address of the top of the locals stack), adding an offset, and performing the read or write. I should clarify that a little. Your locals are *not* loaded into an array at runitme. They are just sitting there on the locals stack. I simply mean that accessing them is merely a matter of indexing into the locals stack (address+offset) as if it were an array.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-16 14:28 -0400 |
| Message-ID | <mgouv1$c3p$1@dont-email.me> |
| In reply to | #38217 |
On 4/16/2015 4:12 AM, Mark Wills wrote:
> On Wednesday, 15 April 2015 22:18:58 UTC+1, lehs wrote:
>> Those locals would facilitate for c-programmers to use Forth. How efficient is it?
>
> Hi Lehs
>
> I would say they are "quite efficient". Basically, at runtime, your locals are loaded into an array. Reading and writing from/to the locals is a case of taking the base address of the locals (i.e. the address of the top of the locals stack), adding an offset, and performing the read or write.
>
> The following code:
>
> : TEST ( -- )
> LOCALS{ n }
> 99 set n
> n .
> ;
>
> Produces the following code:
>
> DOCOL \ standard forth word nest
> 1 (allotLocals) \ reserve space for 1 local on the locals stack
> 99 0 (set) \ write 99 to the first local (n)
> 0 @local \ fetch it back (it's now on the stack)
> dot \ display it
> 1 (freeLocals) \ clean up locals stack
> exit \ return to calling word
>
> So, you can see, for a colon def that contains a local(s), there
> is a call to (allotLocals) and (freeLocals), and other than that
> there is just the call to (set) and @local as you read and write
> your locals.
>
> In my implementation, (set) and @local are written in high-level
> Forth. They are simply:
>
> : (SET) ( value offset -- )
> \ at runtime, set a local variable to to value value
> _LS + ! ;
>
> : @local ( index -- n )
> \ fetch a local from the local stack
> _LS + @ ;
>
> These are of course excellent candidates for hand-writing in
> assembler (on non-optimising systems such as mine). But I would
> say in systems such as VFX and Swift, Mecrisp etc there would be
> no need. They compile optimised native machine code, so they are
> better left as high-level code. Note though that those systems
> (at least VFX and Swift) already support locals, but not my
> non-standard, home-grown variant, obviously.
I expect I have a very different view of efficiency than most of the
people here. I work at the hardware level, including FPGAs, so that to
me any instruction that takes up more than one word and uses more than
one clock cycle is a candidate for improvement. lol
So I see a lot of other operations going on to manage the locals stack
and the extra ops involved in addressing the local. But then I suppose
that needs to be balanced against the equivalent stack oriented code
which may have a number of hoop jumping and la-de-da stack ops. I'm not
a fan of stack juggling. That's one reason why I like the J1 processor.
It has some extensions that minimize stack juggling.
Is there any reason why the words (set) and @local can't be inlined? I
expect they are very simple words, no? I assume the offset specified in
"99 0 (set)" is already converted to address units, right? Hard to tell
with a zero.
--
Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-16 14:37 -0400 |
| Message-ID | <mgovf3$ein$1@dont-email.me> |
| In reply to | #38233 |
On 4/16/2015 2:28 PM, rickman wrote:
> On 4/16/2015 4:12 AM, Mark Wills wrote:
>> On Wednesday, 15 April 2015 22:18:58 UTC+1, lehs wrote:
>>> Those locals would facilitate for c-programmers to use Forth. How
>>> efficient is it?
>>
>> Hi Lehs
>>
>> I would say they are "quite efficient". Basically, at runtime, your
>> locals are loaded into an array. Reading and writing from/to the
>> locals is a case of taking the base address of the locals (i.e. the
>> address of the top of the locals stack), adding an offset, and
>> performing the read or write.
>>
>> The following code:
>>
>> : TEST ( -- )
>> LOCALS{ n }
>> 99 set n
>> n .
>> ;
>>
>> Produces the following code:
>>
>> DOCOL \ standard forth word nest
>> 1 (allotLocals) \ reserve space for 1 local on the locals stack
>> 99 0 (set) \ write 99 to the first local (n)
>> 0 @local \ fetch it back (it's now on the stack)
>> dot \ display it
>> 1 (freeLocals) \ clean up locals stack
>> exit \ return to calling word
>>
>> So, you can see, for a colon def that contains a local(s), there
>> is a call to (allotLocals) and (freeLocals), and other than that
>> there is just the call to (set) and @local as you read and write
>> your locals.
>>
>> In my implementation, (set) and @local are written in high-level
>> Forth. They are simply:
>>
>> : (SET) ( value offset -- )
>> \ at runtime, set a local variable to to value value
>> _LS + ! ;
>>
>> : @local ( index -- n )
>> \ fetch a local from the local stack
>> _LS + @ ;
>>
>> These are of course excellent candidates for hand-writing in
>> assembler (on non-optimising systems such as mine). But I would
>> say in systems such as VFX and Swift, Mecrisp etc there would be
>> no need. They compile optimised native machine code, so they are
>> better left as high-level code. Note though that those systems
>> (at least VFX and Swift) already support locals, but not my
>> non-standard, home-grown variant, obviously.
>
> I expect I have a very different view of efficiency than most of the
> people here. I work at the hardware level, including FPGAs, so that to
> me any instruction that takes up more than one word and uses more than
> one clock cycle is a candidate for improvement. lol
>
> So I see a lot of other operations going on to manage the locals stack
> and the extra ops involved in addressing the local. But then I suppose
> that needs to be balanced against the equivalent stack oriented code
> which may have a number of hoop jumping and la-de-da stack ops. I'm not
> a fan of stack juggling. That's one reason why I like the J1 processor.
> It has some extensions that minimize stack juggling.
>
> Is there any reason why the words (set) and @local can't be inlined? I
> expect they are very simple words, no? I assume the offset specified in
> "99 0 (set)" is already converted to address units, right? Hard to tell
> with a zero.
If you really wanted to make literals fast, you could allocate a
register as the locals stack pointer. Then (set) and @local become
stack relative machine instructions on most computers. But as you say,
any Forth that optimizes at the machine code level will likely do that
anyway.
--
Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-17 04:43 -0700 |
| Message-ID | <173a4d43-6af4-40d7-bbab-58fb22245c03@googlegroups.com> |
| In reply to | #38233 |
On Thursday, 16 April 2015 19:28:44 UTC+1, rickman wrote:
> So I see a lot of other operations going on to manage the locals stack
> and the extra ops involved in addressing the local. But then I suppose
> that needs to be balanced against the equivalent stack oriented code
> which may have a number of hoop jumping and la-de-da stack ops. I'm not
> a fan of stack juggling. That's one reason why I like the J1 processor.
> It has some extensions that minimize stack juggling.
>
Hi Rick
Depends on your interpretation of "a lot" I suppose! Here's the code
that de-allocates locals on the locals stack:
: (freeLocals) ( n -- ) \ runtime code to de-allocate n locals
CELLS +TO _LS ;
That could optimise to a single machine code instruction on some
architectures, or, at most, two instructions. For example, TMS9900:
ADD *SP+,@locstack
*SP+ takes the top value from the datastack (n), adjusting the
datastack register as it does so (post increment), and adds the
value of n to whatever value is stored in memory location locstack.
A further optimisation would be to have locstack in a register, rather
than a memory address.
Here's the code that allocates locals stack space:
: (allotLocals) ( n -- ) \ runtime code to allot n locals on locals stack
\ stack grows towards lower memory addresses
CELLS DUP NEGATE +TO _LS
_LS SWAP 0 FILL ( intialise n locals to 0) ;
I would say that's three machine code instructions on the 9900,
and a subroutine call to FILL.
So, I think the code is actually quite efficient. Or rather, on
an optimising system, it certainly has the potential to be.
As mentioned up-thread, accessing the locals stack at runtime is
just a matter of adding an offset to the top of the stack address,
effectively accessing it like an array. Most modern CPUs can do
that in a single instruction (relative addressing).
Mark
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-14 14:53 +0000 |
| Message-ID | <2015Apr14.165341@mips.complang.tuwien.ac.at> |
| In reply to | #38179 |
rickman <gnuarm@gmail.com> writes:
>I would have thought they could be addressed while on the stack, but I
>suppose they would be in the way of normal use of the stack. So they
>must be pulled off and stored somewhere. I suppose space is allocated
>in the dictionary without a header. But if something else is allocated
>while the local is in use, that space could not be freed up when the
>local scope is exited.
>
>So how dem do dat?
The contents of locals (at run-time) tend to live on the return stack
or a dedicated locals stack. They can also live in registers while in
the definition where they are defined, with spilling to, say, the
return stack if there are too many or when another definition is
called.
The names of the locals need to be stored at compile time somewhere.
If the code is stored in the dictionary, the dictionary is not a good
place and the implementor will store them elsewhere; if the code is
stored elsewhere, the dictionary can be used for the locals names.
The locals names are not needed after the definition is finished
(unless you want to decompile with locals names), so the space for
them may be reclaimed when the (compilation of the) definition ends.
- 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 | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2015-04-16 00:34 -0700 |
| Message-ID | <20b6c483-534c-480d-b785-f853e7342140@googlegroups.com> |
| In reply to | #38115 |
On Saturday, April 11, 2015 at 3:16:51 AM UTC-5, lehs wrote: > I really, really like to use local variables. But not to the price of low efficiency and portability. What is the price? Depends. *** What system are you using? *** Probably you care more about actual than about theoretical or potential performance concerns. > And if it is possible to make it run fast, shouldn't there be a standard? ANS Forth has local variables. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-16 00:54 -0700 |
| Message-ID | <c6a54952-17de-4722-96c7-0f5bb5cd7a3b@googlegroups.com> |
| In reply to | #38213 |
Den torsdag 16 april 2015 kl. 09:34:04 UTC+2 skrev Julian Fondren: > On Saturday, April 11, 2015 at 3:16:51 AM UTC-5, lehs wrote: > > I really, really like to use local variables. But not to the price of low efficiency and portability. What is the price? > > Depends. *** What system are you using? *** Probably you care more about > actual than about theoretical or potential performance concerns. > > > And if it is possible to make it run fast, shouldn't there be a standard? > > ANS Forth has local variables. > > > -- Julian Very few seems to use the ANS standard and the theoretical performance is interesting in programs that intend to be portable in "all" ANS Forth systems.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2015-04-16 01:07 -0700 |
| Message-ID | <7d31b0f7-7742-4182-9d86-c7281c042a7c@googlegroups.com> |
| In reply to | #38214 |
On Thursday, April 16, 2015 at 2:54:44 AM UTC-5, lehs wrote: > Very few seems to use the ANS standard and the theoretical performance is interesting in programs that intend to be portable in "all" ANS Forth systems. Very few? If you mean that few use the LOCALS| | syntax , sure -- but that's irrelevant. If you mean that few systems follow ANS, then I'd say this is really just a statement about which systems have caught your eye for whatever reason. If you're not interested in any actual system's actual performance, not even that of a list of actual systems, then I'm sure you'll get some kind of roughly equivalently non-concrete answer after some indefinite period of waiting, from some kind of humanoid, possibly. What I suggest is that you pick a few systems, search clf for previous statements about their locals performance, and then make inferences or ask questions based on those statements. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-16 12:22 +0000 |
| Message-ID | <2015Apr16.142235@mips.complang.tuwien.ac.at> |
| In reply to | #38214 |
lehs <skydda.barnen@gmail.com> writes:
>Very few seems to use the ANS standard
If you are interested in portable programs, ANS Forth (Forth-94) and
its successor Forth-2012 are your best bet.
While not every system supports the Forth-2012 locals syntax {: ... :}
out of the box yet, you can add this syntax yourself easily by
downloading and unzipping
http://www.forth200x.org/forth200x-code.zip
and then including forth200x-code/extensions/parse-name.fs and
forth200x-code/extensions/locals.fs.
I have just tried it, and it works with VFX Forth 4.71 (which also
includes {: out of the box), SwiftForth 3.2.1 (from 2009), iforth-2.1
(from 2007), and Gforth 0.7.0 (from 2008).
> and the theoretical performance is interesting in programs that intend to be portable in "all" ANS Forth systems.
In theory, you can compile equivalent code with and without locals to
the same machine code; in particular, if you go for maximum
performance, you map both stack items and locals to registers for as
big regions as you can, and you will see pretty much the same
performance from either kind of code, even if the code is not exactly
the same.
In practice, a number of popular Forth compilers are not there yet
(the current iForth may be, but I don't know), and you will typically
see a slowdown by a constant factor from locals over stack
manipulating code.
In practice, you don't use the fastest algorihms yet, so worrying
about constant factors on the order of the difference between locals
and stack manipulation fits the phrase "penny-wise and pound-foolish".
If you find it easier to program fast algorithms using locals, do so;
you can convert it to stack-manipulating code later, if you want.
- 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 | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-16 08:32 -0700 |
| Message-ID | <b76d50e6-94ea-46c2-a652-69aded1ea220@googlegroups.com> |
| In reply to | #38224 |
Den torsdag 16 april 2015 kl. 15:40:37 UTC+2 skrev Anton Ertl:
> lehs <skydda.barnen@gmail.com> writes:
> >Very few seems to use the ANS standard
>
> If you are interested in portable programs, ANS Forth (Forth-94) and
> its successor Forth-2012 are your best bet.
>
> While not every system supports the Forth-2012 locals syntax {: ... :}
> out of the box yet, you can add this syntax yourself easily by
> downloading and unzipping
>
> http://www.forth200x.org/forth200x-code.zip
>
> and then including forth200x-code/extensions/parse-name.fs and
> forth200x-code/extensions/locals.fs.
>
> I have just tried it, and it works with VFX Forth 4.71 (which also
> includes {: out of the box), SwiftForth 3.2.1 (from 2009), iforth-2.1
> (from 2007), and Gforth 0.7.0 (from 2008).
>
> > and the theoretical performance is interesting in programs that intend to be portable in "all" ANS Forth systems.
>
> In theory, you can compile equivalent code with and without locals to
> the same machine code; in particular, if you go for maximum
> performance, you map both stack items and locals to registers for as
> big regions as you can, and you will see pretty much the same
> performance from either kind of code, even if the code is not exactly
> the same.
>
> In practice, a number of popular Forth compilers are not there yet
> (the current iForth may be, but I don't know), and you will typically
> see a slowdown by a constant factor from locals over stack
> manipulating code.
>
> In practice, you don't use the fastest algorihms yet, so worrying
> about constant factors on the order of the difference between locals
> and stack manipulation fits the phrase "penny-wise and pound-foolish".
> If you find it easier to program fast algorithms using locals, do so;
> you can convert it to stack-manipulating code later, if you want.
>
> - 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/
Thanks for the zip file! I might use this locals as a standard extension for programs intended to be portable.
If I need locals to implement the best algorithms in my big integer attempt I will use them there too.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-16 20:42 -0700 |
| Message-ID | <14f9c9aa-d31c-4dd0-b546-cc88a872e588@googlegroups.com> |
| In reply to | #38230 |
On Thursday, April 16, 2015 at 8:32:43 AM UTC-7, lehs wrote:
> Den torsdag 16 april 2015 kl. 15:40:37 UTC+2 skrev Anton Ertl:
> > While not every system supports the Forth-2012 locals syntax {: ... :}
> > out of the box yet, you can add this syntax yourself easily by
> > downloading and unzipping
> >
> > http://www.forth200x.org/forth200x-code.zip
> Thanks for the zip file! I might use this locals as a standard extension for programs intended to be portable.
Anton's implementation has a bug in it. It initializes the locals right of | to whatever garbage value was in memory previously. If the user forgets to explicitly initialize these locals, his program will behave differently every time that it is run --- this lack of deterministic behavior will make the bug difficult to find.
By comparison, my implementation in the novice package (http://www.forth.org/novice.html) initializes the local right of | to zero. If the programmer forgets to explicitly initialize them, he will discover his bug much more easily.
Another problem with Anton Ertl's implementation is that he uses {: as the word that begins defining the locals. For over 20 years, since prior to ANS-Forth, everybody in the Forth community has used { for this (this is called the John Hopkins Format because that is where it originated about a quarter of a century ago). Anton pulled the rug out from under a huge amount of legacy code with his name change. The reason why he did this, is because SwiftForth uses { for multi-line comments, and he can't contradict Forth Inc. or they will remove him from the Forth-200x committee --- so he betrays the entire Forth community instead.
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web