Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33786
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: uninitialized and implicitly initialized locals |
| Date | 2014-10-09 14:19 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2014Oct9.161959@mips.complang.tuwien.ac.at> (permalink) |
| References | (5 earlier) <2014Oct8.145606@mips.complang.tuwien.ac.at> <V8udnS1fUb2WpqjJnZ2dnUU7-I-dnZ2d@supernews.com> <2014Oct8.173212@mips.complang.tuwien.ac.at> <N_OdnXwI08V58ajJnZ2dnUVZ8nadnZ2d@supernews.com> <OY-dnSPHi8lI7KjJnZ2dnUVZ7tWdnZ2d@supernews.com> |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>
>>>>I'm not going to argue with that advantage, but it's hard to do
>>>>that if you're only allowed to define locals in one place.
>>>
>>> Lifting that restriction is not that hard.
>>
>> Ummm. I don't think that you can really say so for all
>> implementations.
>
>I just read your paper, and it looks rather complex to me.
It is. Therefore I have outlined simpler approaches in
<2014Oct8.180623@mips.complang.tuwien.ac.at> (and
<2014Oct7.173637@mips.complang.tuwien.ac.at>).
For anybody who wants to know what's in the paper, it can be found at
<http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz>.
> If you
>have vanother stack you need yet another stack pointer (we already
>have three!) and you have to be able to allocate that stack somehow
>for every thread.
The locals stack is not tied to the automatic scoping at all. You can
have a locals stack without automatic scoping, and you can have
automatic scoping without locals stack. There are two reasons for the
locals stack:
1) Alignment of FP locals. If we kept locals on the return stack, we
would have to FP-align the return stack in a lot of places. On 32-bit
machines this costs padding space on the return stack and, if we want
to minimize padding, extra complexity.
2) Lift the Forth-94 restructions on combining return stack usage and
locals usage without introducing a lot of complexity.
>Also, the compiler has to keep track of lifetimes
>at control flow joins and splits.
In the approach described in the paper, the lifetime is determined by
the visibility, so that comes automatic with the scoping.
In the approach described in
<2014Oct7.173637@mips.complang.tuwien.ac.at>, all locals have space
reserved for them from the first local definition until the end of the
definition, and there is no need to keep track of the lifetimes.
>>> Well, uninitialized locals make Gforth more complex than it is at
>>> present, and they provide exactly zero benefit.
...
>And having read your paper, I'm still not aware that there is any
>problem implementing uninitialized locals. In your notation, the
>runtime action is 0DEADBEEF >L (or DUP >L, to taste) for each local,
>which is more complex than just >L , but not very much more so.
Yes, the code generation of the non-initialization increases the
complexity only slightly once you are there (but it does increase it).
Supporting the additional syntax is more effort. Still nothing
unsurmountable, but given that it provides 0 benefit ...
Looking at code for { (and {:) without and with the "uninitialized
locals" part, that additional complexity is actually significant:
Hayes [hayes92] already mentioned the possibility of uninitialized
locals, but implemented only the part without uninitialized locals and
left uninitialized locals as an "exercise to the reader".
When I created a downloadable form of his work
<http://www.complang.tuwien.ac.at/forth/anslocal.fs>, I considered
implementing the | part as suggested, but did not pull it through.
The result takes 21 lines of code, including >IN manipulation (which
is not present in some of the variants below).
I also did not implement | in Gforth (which uses quite a different
implementation approach); I think the reason is that in both cases the
additional complexity appeared excessive.
Stephen Pelc's "reference implementation" of {: with |
<http://www.forth200x.org/locals-v5.txt> assumes a magic word BUILDLV
whose implementation is not provided, and then still needs 55 lines of
code.
My first attempt at a reference implementation based on (LOCAL)
<http://www.forth200x.org/reference-implementations/extended-locals.fs>
takes 44 lines of code, and would be even longer if we used WORD and
>IN like anslocal.fs (instead, we use PARSE-NAME).
I later forgot about that implementation and made another one, this
time finding a better approach, resulting in 23 lines of code
<http://www.forth200x.org/reference-implementations/locals.fs>. But
as discussed in <2013Oct30.180302@mips.complang.tuwien.ac.at>, this
version would be longer if it used WORD and >IN like anslocal.fs.
Maybe I should write a version of anslocal.fs with PARSE-NAME to show
the real difference.
@Article{hayes92,
author = "John R. Hayes",
title = "User-Defined Local Variable Syntax with {ANS Forth}",
journal = sigforth,
year = "1992",
volume = "4",
number = "2",
OPTpages = "19, 20, 26",
annote = "Shows how to define a nice locals syntax using the ANS
Forth locals wordset."
}
- 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/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Why smudge? hughaguilar96@yahoo.com - 2014-09-30 19:25 -0700
Re: Why smudge? november.nihal@gmail.com - 2014-10-01 08:54 -0700
Re: Why smudge? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-01 19:09 +0000
Re: Why smudge? november.nihal@gmail.com - 2014-10-01 10:16 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-01 18:54 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 15:31 -0700
Re: Why smudge? Michael Barry <barrym95838@yahoo.com> - 2014-10-02 16:35 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 17:02 -0700
Re: Why smudge? Michael Barry <barrym95838@yahoo.com> - 2014-10-02 17:51 -0700
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 18:50 -0700
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-04 00:30 +0100
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-03 17:40 -0700
Re: Why smudge? Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-10-03 23:00 -0700
Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-04 21:14 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:42 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Enoch <emc.consultants@gmail.com> - 2014-10-05 10:43 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-05 20:21 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-06 03:58 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-05 17:09 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Michael Barry <barrym95838@yahoo.com> - 2014-10-06 11:15 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-06 18:52 -0700
More ranting Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-07 03:48 -0500
Re: More ranting albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-07 12:43 +0000
Re: More ranting Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:23 +0200
Re: More ranting "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-16 01:03 -0400
Re: More ranting Just Ian <superian@gmail.com> - 2014-10-16 07:14 -0700
Re: More ranting Michael Barry <barrym95838@yahoo.com> - 2014-10-16 13:23 -0700
uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 15:36 +0000
Re: uninitialized and implicitly initialized locals (was: More ranting) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 22:15 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) mhx@iae.nl - 2014-10-07 15:07 -0700
Re: uninitialized and implicitly initialized locals (was: More ranting) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:11 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 13:25 +0000
Re: uninitialized and implicitly initialized locals (was: More ranting) hughaguilar96@yahoo.com - 2014-10-09 16:22 -0700
Re: uninitialized and implicitly initialized locals (was: More ranting) "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 21:58 -0400
Re: uninitialized and implicitly initialized locals (was: More ranting) mhx@iae.nl (Marcel Hendrix) - 2014-10-12 11:18 +0200
Re: uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 12:35 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-07 15:27 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 12:56 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 08:24 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 15:32 +0000
Simplified automatic scoping (was: uninitialized ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 16:06 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 11:57 -0500
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 12:18 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 14:19 +0000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-09 14:42 -0700
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 14:07 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-09 10:44 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-10 16:03 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-10 13:35 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 10:53 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 11:34 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-15 12:44 +0000
Re: uninitialized and implicitly initialized locals albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-15 14:34 +0000
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-15 15:03 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-15 11:10 -0500
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-16 12:19 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-17 03:56 -0500
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-17 07:48 -1000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-17 19:26 -0700
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-18 12:55 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-18 13:21 -0500
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-18 08:44 -1000
Re: uninitialized and implicitly initialized locals albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-19 09:53 +0000
Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-20 12:48 +0000
Re: uninitialized and implicitly initialized locals "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-20 16:24 -0400
Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-20 10:30 -1000
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-20 16:23 -0700
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 04:16 -0500
Re: uninitialized and implicitly initialized locals mhx@iae.nl (Marcel Hendrix) - 2014-10-26 11:32 +0200
Re: uninitialized and implicitly initialized locals stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-26 14:27 +0000
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 13:56 -0500
Re: uninitialized and implicitly initialized locals mhx@iae.nl (Marcel Hendrix) - 2014-10-26 20:32 +0200
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 16:18 -0500
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-26 15:05 -0700
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 17:53 -0500
Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-26 16:30 -0700
Re: uninitialized and implicitly initialized locals "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-27 01:45 -0400
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-27 12:21 -0500
Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 17:57 -0500
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-06 20:55 +0100
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-06 16:05 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-09 07:36 +0100
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-10 01:52 +0000
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-09 19:56 -0700
Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:11 -0400
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-05 11:05 +0100
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-05 19:48 -0700
Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-06 07:53 +0100
Re: Why smudge? "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 21:29 -1000
Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-09 15:16 -0700
Re: Why smudge? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-16 01:03 -0400
csiph-web