Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33600 > unrolled thread
| Started by | hughaguilar96@yahoo.com |
|---|---|
| First post | 2014-09-30 19:25 -0700 |
| Last post | 2014-10-16 01:03 -0400 |
| Articles | 20 on this page of 91 — 16 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: 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
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-06 18:52 -0700 |
| Subject | Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! |
| Message-ID | <8b0123d6-4076-4dce-a0eb-c6163148bf30@googlegroups.com> |
| In reply to | #33720 |
On Monday, October 6, 2014 11:15:23 AM UTC-7, Michael Barry wrote:
> > Here is a new version of my code with DEFINITIONS and GET-CONTEXT
> > fixed so they will work inside of colon definitions at compile-time.
> > This is only a slight upgrade from what I posted previously (once
> > again, comments are removed for brevity).
>
> Hugh, may I politely request that you _not_ remove comments for
> the sake of brevity. It would make learning much easier for me.
When I post code on C.L.F. with a lot of comments, the lines wrap around and it becomes a hard-to-read mess. What I will do however, is email you a copy of novice.4th that includes the commented code --- this will be a pre-release --- I will put an upgrade of the novice package on www.forth.org pretty soon that will include this stuff, but anybody who wants it right now can have it. Send me a private response and tell me what your email address is, and I will send you an email with an attachment of the pre-release novice.4th --- I won't send you any other emails (no spam!).
The code is just ANS-Forth except that I use { to define locals. This is available in the novice package, and there are several other implementations that are compatible. I also have COMMENT to comment out the test code, and COMMENT is available in the novice package. If anybody wants to use this without the novice package, they just need to have { available plus they need to delete the COMMENT and & lines.
Note that Anton Ertl wrote a word {: for defining locals that works like my { except that it does not zero out the locals to the right of the | sign. This doesn't affect code at all --- zeroing out those locals is done to help debugging, so that if the programmer forgets to explicitly initialize them they will be initialized to a known state and the program will behave the same every time that it is run (not behave differently depending upon what garbage values the locals were initialized to) --- consistency is a huge help in debugging --- getting different results with each program run, with no apparent reason, can be mind-blowing! Andrew Haley is most likely aware of this --- he is just playing dumb because he knows that Anton Ertl's code will automatically go into the Forth-200x standard without review, so he doesn't want to criticize it and then have to back down when Anton Ertl ignores him (as Anton Ertl ignored me when he first posted {: and I pointed out the problem with it).
Another strange thing about Anton Ertl's code, is that he named it {: rather than { that has been used in several implementations including mine (all derived from the John Hopkins implementation). He did this because SwiftForth uses { for multi-line comments, and the Forth-200x mandate is that all SwiftForth code has to be Forth-200x compliant without any modification whatsoever --- so, rather than switch to my COMMENT he sticks with { as the multi-line comment word and uses the ugly {: for local definitions --- and to heck with everybody who has been using { for local definitions for many years.
> In the course of my part-time studies, I have seen references to
> numerous Forth stacks: parameter, return, control, leave, float,
> etc. It is my impression that only the first two are omni-present,
> but that the others can provide useful work-arounds for more
> advanced coding techniques. Do you (or anyone else here) have
> any opinions on the use of one of the others for implementing
> locals, or perhaps even a dedicated local stack, if one doesn't
> already exist?
In early Forth implementations (going back to the 1970s and early 1980s), there were severe memory limitations on most boards, and the processors also had only a few registers with non-orthogonal instruction sets (the 8080 was typical of the day). Because of these constraints, there was a tendency to use resources for more than one purpose. This is a bad idea though, because when you have a program that uses a resource for more than one purpose, the code becomes horribly complicated because you may or may not have extraneous stuff in your way. It is really best to have each resource used for only one purpose.
Some examples of this problem in ANS-Forth (just a few):
1.) Local variables "may" be held on the return-stack, rather than have their own stack. The result is that the standard document gives us weird restrictions as the two uses of the return-stack clash (13.3.3):
- Locals shall not be declared until values previously placed on the return stack within the definition have been removed;
- After a definition's locals have been declared, a program may place data on the return stack. However, if this is done, locals shall not be accessed until those values have been removed from the return stack;
2.) Control-flow data "may" be held on the parameter-stack, rather than have their own stack. The result is that, when you write a meta-compiling word (see 1ARRAY etc. in the novice package), you don't have access to the parameter-stack in your compile-time code because there may or may not be control-flow data on top of your data (even colon itself sometimes pushes control-flow data), and you don't know if it is there or not, or how big it is.
3.) Float data "may" be held on the parameter-stack, but we don't know how big the float data is.
4.) Double-size data is held on the parameter-stack along with single-size data. This can be worked with, because you know how big it is (two cells), but it results in a lot of complicated stack-juggling that could be gotten rid of if the doubles had their own stack distinct from the singles.
In my language, I will have all of these things separated so they don't clash.
When Pelc uses the word-list search-order stack for internal uses, he is following this same bad pattern --- he is using a resource that is supposed to be for the programmer's exclusive use, for internal system use. His attitude seems to be: "Well, I will just push LOCALVARS on top of the user's wids, and the user will just have to notice this and work around it, and VFX still gets to be called ANS-Forth compliant even though VFX will no longer run ANS-Forth programs that don't work around VFX's internal use of this public resource."
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-07 03:48 -0500 |
| Subject | More ranting |
| Message-ID | <qsidnSWZzPB2Na7JnZ2dnUU7-YudnZ2d@supernews.com> |
| In reply to | #33723 |
hughaguilar96@yahoo.com wrote:
>
> The code is just ANS-Forth except that I use { to define
> locals. This is available in the novice package, and there are
> several other implementations that are compatible. I also have
> COMMENT to comment out the test code, and COMMENT is available in
> the novice package. If anybody wants to use this without the novice
> package, they just need to have { available plus they need to delete
> the COMMENT and & lines.
>
> Note that Anton Ertl wrote a word {: for defining locals that works
> like my { except that it does not zero out the locals to the right
> of the | sign. This doesn't affect code at all --- zeroing out those
> locals is done to help debugging,
That won't help debugging at all.
> so that if the programmer forgets to explicitly initialize them they
> will be initialized to a known state and the program will behave the
> same every time that it is run (not behave differently depending
> upon what garbage values the locals were initialized to) ---
> consistency is a huge help in debugging --- getting different
> results with each program run, with no apparent reason, can be
> mind-blowing! Andrew Haley is most likely aware of this --- he is
> just playing dumb because he knows that Anton Ertl's code will
> automatically go into the Forth-200x standard without review, so he
> doesn't want to criticize it and then have to back down when Anton
> Ertl ignores him (as Anton Ertl ignored me when he first posted {:
> and I pointed out the problem with it).
For what it's worth, I am on record as really disliking this way of
declaring locals:
https://groups.google.com/d/msg/comp.lang.forth/5FM16LcHvo8/Lv4hw3DB8_IJ
It was a long time ago, but IIRC I argued in the Forth 200x meeting
against it going in. However, it was explained to me that it was in
use in many projects, with no problems, so I gave up because I was in
a small minority and could not win.
> Another strange thing about Anton Ertl's code, is that he named it
> {: rather than { that has been used in several implementations
> including mine (all derived from the John Hopkins implementation).
There's nothing stange about that: it was done to avoid breaking
existing code.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-07 12:43 +0000 |
| Subject | Re: More ranting |
| Message-ID | <5433dfd9$0$6905$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #33725 |
In article <qsidnSWZzPB2Na7JnZ2dnUU7-YudnZ2d@supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>hughaguilar96@yahoo.com wrote:
>>
>> The code is just ANS-Forth except that I use { to define
>> locals. This is available in the novice package, and there are
>> several other implementations that are compatible. I also have
>> COMMENT to comment out the test code, and COMMENT is
>available in
>> the novice package. If anybody wants to use this
>without the novice
>> package, they just need to have { available plus they
>need to delete
>> the COMMENT and & lines.
>>
>> Note that Anton Ertl wrote a word {: for defining
>locals that works
>> like my { except that it does not zero out the locals
>to the right
>> of the | sign. This doesn't affect code at all ---
>zeroing out those
>> locals is done to help debugging,
>
>That won't help debugging at all.
As a general principle: Hugh is right about this.
I've done more than one complicated debugging job.
The last thing you need is that you can't compare the
results of your small change, because there are other
random gratitious changes resulting from uninitialised
memory.
It may be an exaggeration to say that it *helps* debugging,
but it removes one obstacle that's for sure.
>Andrew.
--
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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-07 16:23 +0200 |
| Subject | Re: More ranting |
| Message-ID | <m10t0o$fh9$2@online.de> |
| In reply to | #33727 |
Albert van der Horst wrote: >>That won't help debugging at all. > > As a general principle: Hugh is right about this. I'm also on Hugh's side here: Never ever do uninitialized somethings. If you want "implicitely initialized", that's fine with me, but then initialize to zero (for values and pointers). Programs simply behave better if you make sure everything is deterministic. If zero isn't the right value to initialize, you'll quickly figure out, and explicitely initialize; but if it's uninitialized, changes are high that it is 95% zero (especially on the first run in the clean system where you enter the definition on the command line to try it), and your program crashes unexpectedly in the 5% where it's "some leftover" instead. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-10-16 01:03 -0400 |
| Subject | Re: More ranting |
| Message-ID | <op.xns4ccbrmk81un@localhost> |
| In reply to | #33729 |
On Tue, 07 Oct 2014 10:23:23 -0400, Bernd Paysan <bernd.paysan@gmx.de> wrote: > If you want "implicitely initialized", [...] > > Bernd Paysan > "If you want it done right, you have to do it yourself" Well, you're still doing it wrong. s/implicitely/implicitly So, I guess that "you" excludes you and means "other people". Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Just Ian <superian@gmail.com> |
|---|---|
| Date | 2014-10-16 07:14 -0700 |
| Subject | Re: More ranting |
| Message-ID | <92f6810d-a0ef-403f-8542-b9eec8afebde@googlegroups.com> |
| In reply to | #33934 |
Rod Pemberton said: > Well, you're still doing it wrong. > > s/implicitely/implicitly When everyone's German is as good as Bernd's English... Ian
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2014-10-16 13:23 -0700 |
| Subject | Re: More ranting |
| Message-ID | <b98fc861-ba0a-4f4e-a420-7b62865049dc@googlegroups.com> |
| In reply to | #33944 |
On Thursday, October 16, 2014 7:14:45 AM UTC-7, Just Ian wrote: > > When everyone's German is as good as Bernd's English... > I agree. His written English is certainly adequate for my needs, and he seems to favor politeness over rudeness, at least when unprovoked, which is much more than I can say for some ... Mike
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-07 15:36 +0000 |
| Subject | uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <2014Oct7.173637@mips.complang.tuwien.ac.at> |
| In reply to | #33727 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <qsidnSWZzPB2Na7JnZ2dnUU7-YudnZ2d@supernews.com>,
>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>>hughaguilar96@yahoo.com wrote:
>>>
>>> The code is just ANS-Forth except that I use { to define
>>> locals. This is available in the novice package, and there are
>>> several other implementations that are compatible. I also have
>>> COMMENT to comment out the test code, and COMMENT is
>>available in
>>> the novice package. If anybody wants to use this
>>without the novice
>>> package, they just need to have { available plus they
>>need to delete
>>> the COMMENT and & lines.
>>>
>>> Note that Anton Ertl wrote a word {: for defining
>>locals that works
>>> like my { except that it does not zero out the locals
>>to the right
>>> of the | sign. This doesn't affect code at all ---
>>zeroing out those
>>> locals is done to help debugging,
>>
>>That won't help debugging at all.
>
>As a general principle: Hugh is right about this.
>I've done more than one complicated debugging job.
>The last thing you need is that you can't compare the
>results of your small change, because there are other
>random gratitious changes resulting from uninitialised
>memory.
As it happens, I made a reference implementation for the {: proposal
based on (LOCAL)
<http://www.forth200x.org/reference-implementations/extended-locals.fs>,
and that implementation uses a fixed value (12345) for initializing
the locals after "|". I did not use 0, because that is more likely to
hide a bug that might surface on an implementation that really does
not initialize. The fixed value was necessitated by the fundament on
which I built {: (there is no uninitialized local with (LOCAL)), but
maybe I would have done it even if I had, say (UNINITIALIZED-LOCAL),
at my disposal.
Indeed I think that both uninitialized and implicitly initialized
locals are a bad idea in most cases. The way to go is to define the
local when you have the initial value for it, and with Gforth's locals
that is possible in all but very few cases.
The desire for uninitialized locals was vehemently expressed by a
vendor whose locals implementation imposes restrictions that make it
impossible in many cases to define a local when you have the initial
value for it. So his idea is to define locals uninitialized in a
place where his locals implementation allows you to define locals, and
then initialize it later, with TO.
Hmm, given that he still implements all locals on the in-memory return
stack, it should not be that hard to extend his implementation to
accept something close to the Gforth-supported usage, with one
restriction still remaining: The first locals definition must happen
outside any control structure. When you see another locals
definition, you backpatch the return-stack reservation produced by the
first locals definition to increase the number of reserved locals, and
store the newly defined locals in the new slots.
He would also need to implement the scoping of locals, and that can
also be done in a single pass (and is done so by Gforth), but my guess
is that he did not like the define-locals-where-needed approach
because of code generation issues.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-07 22:15 +0200 |
| Subject | Re: uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <m11hla$ffe$1@online.de> |
| In reply to | #33732 |
Anton Ertl wrote:
> Hmm, given that he still implements all locals on the in-memory return
> stack, it should not be that hard to extend his implementation to
> accept something close to the Gforth-supported usage, with one
> restriction still remaining: The first locals definition must happen
> outside any control structure. When you see another locals
> definition, you backpatch the return-stack reservation produced by the
> first locals definition to increase the number of reserved locals, and
> store the newly defined locals in the new slots.
I don't see any need for this sort of restriction; the only problem of using
the return stack for locals is when your code contains >r and r>, and
declares the locals in between.
So let's see how VFX does cope with that today:
: test >r { a b } a b + r> . . ; ok
1 2 3 test 134520832 3
CS=0023 DS=002B ES=002B SS=002B FS=0000 GS=0063
EAX=0000:0001 EBX=091A:F000 ECX=091A:EF78 EDX=0000:0001
ESI=091C:0000 EDI=080B:F345 EBP=091B:EFC4 ESP=091A:EFB0
EIP=0000:0003 EFLAGS=0001:0207
--- RS top ---
Oops. So I would declare that possible problem a non-issue, because it
doesn't work right now, either, and it fails, because declaring locals
pushes a "clean up the locals" address on the return stack.
If your >r and r> are balanced without declaring new locals in between (and
VFX can handle that quite well), you can just allocate locals on the return
stack using exactly the same algorithm we use in Gforth to allocate locals
on the locals stack.
> He would also need to implement the scoping of locals, and that can
> also be done in a single pass (and is done so by Gforth), but my guess
> is that he did not like the define-locals-where-needed approach
> because of code generation issues.
Actually, with an analytical compiler, locals could be implemented "right",
i.e. it is just a virtual register, assigned to a value on the stack, given
a place on a virtual locals stack (which may actually live on the return
stack, but allocation of the maximum space needed in a word is moved to the
beginning, and deallocation is attached to every compiled EXIT) to be saved
when the register allocater runs out of registers (or needs to caller-save
registers when calling other words), and that's it - only those locals which
need saving in between need to be allocated on that stack, all locals that
can be kept in registers and are dead before they need saving don't. That's
what an analytical compiler is for, to take the whole word, and analyze the
total dataflow within. The sequence above { a b } a b + should compile to
the same code as a simple +.
It's just that in VFX, locals are second class to the optimizer, because
they don't happen enough to be worth the effort. That's a tradeoff
decision, MPE can't do everything.
BTW, that's what iForth 4.06 (64 bit Linux version, the last trial version I
have) does on the code above (properly Marcelified):
FORTH> : test >r params| a b | a b + r> . . ; ok
FORTH> 1 2 3 test 3 3 ok
So others have done some more effort ;-). The code it generates doesn't
fully convince me, but it is at least doing what you might expect.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2014-10-07 15:07 -0700 |
| Subject | Re: uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <658808e2-74fc-47d0-8d54-85f51e1466e2@googlegroups.com> |
| In reply to | #33737 |
On Tuesday, October 7, 2014 10:15:43 PM UTC+2, Bernd Paysan wrote: > BTW, that's what iForth 4.06 (64 bit Linux version, the last trial version I > have) does on the code above (properly Marcelified): > FORTH> : test >r params| a b | a b + r> . . ; ok > FORTH> 1 2 3 test 3 3 ok > So others have done some more effort ;-). The code it generates doesn't > fully convince me, but it is at least doing what you might expect. Well, the generator does not expect illogical combinations of R-stack use and locals :-) FORTH> : (test) params| a b c | a b + c ; : test 1 2 3 (test) . . ; ok FORTH> see test Flags: ANSI $01223200 : test $0122320A push 3 b# $0122320C push 3 b# $0122320E lea rbp, [rbp -8 +] qword $01223212 mov [rbp 0 +] qword, $0122321F d# $0122321A jmp .+10 ( $0113A97A ) offset NEAR $0122321F jmp .+10 ( $0113A97A ) offset NEAR $01223224 ; FORTH> : test2 1 2 3 (test) + drop ; ok FORTH> ' test2 idis $01223240 : test2 $0122324A ; -marcel
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-08 03:11 +0200 |
| Subject | Re: uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <m1230r$etn$1@online.de> |
| In reply to | #33740 |
mhx@iae.nl wrote: > On Tuesday, October 7, 2014 10:15:43 PM UTC+2, Bernd Paysan wrote: >> BTW, that's what iForth 4.06 (64 bit Linux version, the last trial >> version I have) does on the code above (properly Marcelified): > >> FORTH> : test >r params| a b | a b + r> . . ; ok >> FORTH> 1 2 3 test 3 3 ok > >> So others have done some more effort ;-). The code it generates doesn't >> fully convince me, but it is at least doing what you might expect. > > Well, the generator does not expect illogical combinations of R-stack use > and locals :-) Probably, but at least the code does not fall flat on its face, which is probably good enough for this sort of "being cruel to the compiler" code ;-). > FORTH> : (test) params| a b c | a b + c ; : test 1 2 3 (test) . . ; ok > FORTH> see test > Flags: ANSI > $01223200 : test > $0122320A push 3 b# > $0122320C push 3 b# > $0122320E lea rbp, [rbp -8 +] qword > $01223212 mov [rbp 0 +] qword, $0122321F d# > $0122321A jmp .+10 ( $0113A97A ) offset NEAR > $0122321F jmp .+10 ( $0113A97A ) offset NEAR > $01223224 ; BTW: I know you have made the design decision of using rsp as data stack, and rbp as return stack. The consequence is that you can't use call, but you have to push return addresses pretty much manually on the return stack. That comes at a cost: the CPU actually has an internal return stack used to predict rets (to a limited level of call depth, which is probably enough for Forth to work almost perfectly). The costs of using something other than esp as data stack comes at a cost, too - you can't do push/pop. The way push/pop are implemented now probably means just more code space used, but no performance degradation if you do it manually - actually, IIRC, the Pentium was the last x86 CPU which could do two pushs or pops in one cycle; starting with the Pentium Pro, there's a sp update register dependency which prevents the CPU to do more than one push/pop per cycle, while you certainly can do more than one of those moves with offset per cycle (as long as you merge all stack pointer updates to the start/end of one basic block). Have you done some calculation on the tradeoffs? I'm pretty sure I would go for rsp as return stack, and rbp or some other easily used pointer register as data stack, even though then push/pop sequences are out of question. But that's because Intel has stopped making them run real fast a long time ago. > FORTH> : test2 1 2 3 (test) + drop ; ok > FORTH> ' test2 idis > $01223240 : test2 > $0122324A ; If I take the . . out, the code generated looks perfect, een with my cruel- to-compiler variant. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-08 13:25 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <2014Oct8.152522@mips.complang.tuwien.ac.at> |
| In reply to | #33744 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>The way
>push/pop are implemented now probably means just more code space used, but
>no performance degradation if you do it manually - actually, IIRC, the
>Pentium was the last x86 CPU which could do two pushs or pops in one cycle;
>starting with the Pentium Pro, there's a sp update register dependency which
>prevents the CPU to do more than one push/pop per cycle, while you certainly
>can do more than one of those moves with offset per cycle (as long as you
>merge all stack pointer updates to the start/end of one basic block).
I dimly remember special optimizations for pushes and pops in CPUs
more recent than the Pentium (too dim to remember whether that was
done by Intel or by AMD). But certainly, if the compiler is not
totally naive, the data stack pointer updates should not be that
frequent (and should cost almost nothing, as there is probably some
ALU around that would otherwise go unused).
- 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-09 16:22 -0700 |
| Subject | Re: uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <f943cfd5-db7e-4e80-8d71-e10c6e210242@googlegroups.com> |
| In reply to | #33740 |
On Tuesday, October 7, 2014 3:07:01 PM UTC-7, m...@iae.nl wrote: > Well, the generator does not expect illogical combinations of R-stack use > and locals :-) Using both >R and locals is only "illogical" if a person assumes that locals are on the return-stack --- but why would anybody assume this??? In VFX's "Tip of the Day" file we have this: "Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer." Fred Brooks, Jr. In 13.3.3 we have this rule that you apparently consider to be perfectly logical: - Locals shall not be declared until values previously placed on the return stack within the definition have been removed; - After a definition's locals have been declared, a program may place data on the return stack. However, if this is done, locals shall not be accessed until those values have been removed from the return stack; I expect that most people learning Forth would find such a rule to be "capricious or arbitrary" --- maybe that is why so few are volunteering to learn Forth, do you think?
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-10-17 21:58 -0400 |
| Subject | Re: uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <op.xnwk4igymk81un@localhost> |
| In reply to | #33794 |
On Thu, 09 Oct 2014 19:22:12 -0400, <hughaguilar96@yahoo.com> wrote: > In 13.3.3 we have this rule that you apparently consider to be perfectly > logical: > > - Locals shall not be declared until values previously placed on the > return stack within the definition have been removed; > - After a definition's locals have been declared, a program may place > data on the return stack. However, if this is done, locals shall not be > accessed until those values have been removed from the return stack; > > I expect that most people learning Forth would find such a rule to be > "capricious or arbitrary" --- maybe that is why so few are volunteering > to learn Forth, do you think? That says a return stack is a stack and must be used like a stack. It says a return stack is not an addressable array or register file. How is a stack being used as a stack arbitrary and capricious? ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2014-10-12 11:18 +0200 |
| Subject | Re: uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <78179291938433@frunobulax.edu> |
| In reply to | #33740 |
Bernd Paysan <bernd.paysan@gmx.de> writes Re: uninitialized and implicitly initialized locals (was: More ranting) > BTW: I know you have made the design decision of using rsp as data stack, > and rbp as return stack. The consequence is that you can't use call, but > you have to push return addresses pretty much manually on the return stack. Actually no, iForth uses <call> if you instruct it to do so by inverting this entry in iForth.prf: [DEFINED] XCALL-used@ [IF] TRUE XCALL-used! ( jmp imm | call ) [THEN] E.g. FORTH> TRUE XCALL-used! ok FORTH> : (test) params| a b c | a b + c ; : test 1 2 3 (test) . . ; ok FORTH> see test Flags: ANSI $01220A80 : test $01220A8A push 3 b# $01220A8C push 3 b# $01220A8E lea rbp, [rbp -8 +] qword $01220A92 mov [rbp 0 +] qword, $01220A9F d# $01220A9A jmp .+10 ( $0113A97A ) offset NEAR $01220A9F jmp .+10 ( $0113A97A ) offset NEAR $01220AA4 ; FORTH> FALSE XCALL-used! ok FORTH> : (test) params| a b c | a b + c ; : test 1 2 3 (test) . . ; Redefining (test) Redefining test ok FORTH> see test Flags: ANSI $01220B40 : test $01220B4A push 3 b# $01220B4C push 3 b# $01220B4E call . ( $0113A970 ) offset NEAR $01220B53 jmp .+10 ( $0113A97A ) offset NEAR $01220B58 ; You may note that all iForth non-inlined words have a standard prologue than can be skipped. > That comes at a cost: the CPU actually has an internal return stack used to > predict rets (to a limited level of call depth, which is probably enough for > Forth to work almost perfectly). The costs of using something other than > esp as data stack comes at a cost, too - you can't do push/pop. The way > push/pop are implemented now probably means just more code space used, but > no performance degradation if you do it manually - actually, IIRC, the > Pentium was the last x86 CPU which could do two pushs or pops in one cycle; > starting with the Pentium Pro, there's a sp update register dependency which > prevents the CPU to do more than one push/pop per cycle, while you certainly > can do more than one of those moves with offset per cycle (as long as you > merge all stack pointer updates to the start/end of one basic block). This is the theory, and I looked into that a long time ago. At that time, in practice, push and pop proved to be slow no matter what I did. TRUE XCALL-used! is better than FALSE XCALL-used!. One possible explanation might be that the internal return stack looked at ALL rsp-related operations (not just calls). At the time, I thought having 16 registers would minimize the number of push/pops to a very low number and that therefore the effect, if it existed at all, would not be noticeable. Maybe I should do these benchmarks again. Experiments with mxforth (oh my, how long ago that is) indicated that having rbp for the datastack is MUCH better than rsp. Also, caching the top of the (rbp) data stack in a register is much better than letting the compiler allocate it, especially if I want to win a particular standard (recursive) benchmark. > Have you done some calculation on the tradeoffs? I'm pretty sure I would go > for rsp as return stack, and rbp or some other easily used pointer register > as data stack, even though then push/pop sequences are out of question. But > that's because Intel has stopped making them run real fast a long time ago. At the time I wanted to make it possible that a C function could call Forth directly. Changing rbp<->rsp is on my list of things to do. (It is a long list and at the moment I much prefer using Forth over 'improving' it). -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-08 12:35 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals (was: More ranting) |
| Message-ID | <2014Oct8.143546@mips.complang.tuwien.ac.at> |
| In reply to | #33737 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Hmm, given that he still implements all locals on the in-memory return
>> stack, it should not be that hard to extend his implementation to
>> accept something close to the Gforth-supported usage, with one
>> restriction still remaining: The first locals definition must happen
>> outside any control structure. When you see another locals
>> definition, you backpatch the return-stack reservation produced by the
>> first locals definition to increase the number of reserved locals, and
>> store the newly defined locals in the new slots.
>
>I don't see any need for this sort of restriction; the only problem of using
>the return stack for locals is when your code contains >r and r>, and
>declares the locals in between.
This is not about the return stack. It would also be relevant with
such an implementation with a separate locals stack (indeed I started
out without specifying on which stack the locals were stored, and then
made it more concrete for easier unterstanding; but apparently also
easier misunderstanding).
This is about words like (from the Gforth tutorial):
: strcmp {: addr1 u1 addr2 u2 -- n :}
addr1 addr2
u1 u2 min 0
?do {: s1 s2 :}
s1 c@ s2 c@ -
?dup-if
unloop exit
then
s1 char+ s2 char+
loop
2drop
u1 u2 - ;
Because some systems cannot do this, we got the uninitialized locals,
so that code could be rewritten as:
: strcmp {: addr1 u1 addr2 u2 | s1 s2 -- n :}
addr1 addr2
u1 u2 min 0
?do to s2 to s1
s1 c@ s2 c@ -
?dup-if
unloop exit
then
s1 char+ s2 char+
loop
2drop
u1 u2 - ;
I am claiming that the compiler can do that for the programmer with
relatively little effort. The restriction I mentioned is to disallow
having the first locals definition inside a control structure, like
here:
: foo ( ... ) \ no locals definition here:
... begin {: a b :}
... while
... repeat
... ;
If you allow that, either the backpatching does not just need to
update the space used by locals, but has to insert the locals
allocation in the code before the control structure, or you have to
generate matched allocation and deallocation on every iteration the
way Gforth does it; but the latter option is probably seen as too
inefficient by the implementor (one argument for uninitialized locals
was efficiency).
>Actually, with an analytical compiler, locals could be implemented "right",
>i.e. it is just a virtual register, assigned to a value on the stack, given
>a place on a virtual locals stack (which may actually live on the return
>stack, but allocation of the maximum space needed in a word is moved to the
>beginning, and deallocation is attached to every compiled EXIT) to be saved
>when the register allocater runs out of registers (or needs to caller-save
>registers when calling other words), and that's it - only those locals which
>need saving in between need to be allocated on that stack, all locals that
>can be kept in registers and are dead before they need saving don't. That's
>what an analytical compiler is for, to take the whole word, and analyze the
>total dataflow within. The sequence above { a b } a b + should compile to
>the same code as a simple +.
Sure, that would be the way to go, but that's a bigger project. What
I wanted to point out is that it does not take such a big effort to
remove the restrictions that led to uninitialized locals.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-07 15:27 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <svadnTUPuZtd0anJnZ2dnUU7-fWdnZ2d@supernews.com> |
| In reply to | #33732 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Indeed I think that both uninitialized and implicitly initialized > locals are a bad idea in most cases. The way to go is to define the > local when you have the initial value for it, and with Gforth's locals > that is possible in all but very few cases. I partly agree. In most cases I think you'd initialize the local with some value. I don't much see the point of locals initialized to some canonical "magic" value because the initial value is necesarily application-dependent; maybe 0, maybe 1, maybe -1. On the other hand, if someone really wants to create an uninitialized local I can't see much harm in it. Even where the specification allows a local to be uninitialized, an implementation could use DEADBEEF, and that's a good idea. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-08 12:56 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct8.145606@mips.complang.tuwien.ac.at> |
| In reply to | #33738 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> On the other hand,
>if someone really wants to create an uninitialized local I can't see
>much harm in it.
The benefit of defining a local where it is properly initialized is
that every read from the local produces a proper value. You cannot
read the uninitialized value.
Does someone really *want* to create an uninitialized local, or is it
just that the programming language does not support what the
programmer really wants, and the uninitialized local is a workaround
for that? E.g., in Forth-2012 the uninitialized local is a workaround
for disallowing to define locals everywhere in a definition.
So the harm of uninitialized locals to the programmer is that he may
make errors that would be caught (as "undefined word") if the locals
were defined later, where they are properly initialized. The harm to
the language is that it allows restrictions such as "only one locals
definition in a colon definition" and "no locals definition inside
control structures" to persist.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-08 08:24 -0500 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <V8udnS1fUb2WpqjJnZ2dnUU7-I-dnZ2d@supernews.com> |
| In reply to | #33753 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> On the other hand, if someone really wants to create an >>uninitialized local I can't see much harm in it. > > The benefit of defining a local where it is properly initialized is > that every read from the local produces a proper value. You cannot > read the uninitialized value. 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. > Does someone really *want* to create an uninitialized local, or is it > just that the programming language does not support what the > programmer really wants, and the uninitialized local is a workaround > for that? E.g., in Forth-2012 the uninitialized local is a workaround > for disallowing to define locals everywhere in a definition. So that's OK, then. Well, it's not OK, it's all we have at present. I'm not going to argue about the programmer convenience of being able to declare locals as required, but it's not that easy for the implementation and it brings up some tricky issues to do with lifetimes. (Which I know you have an answer to in gforth.) All other things being equal, simple implementations are better than complex ones, and locals aren't important enough to justify making implementations any more complex than they are at present. IMO, YMMV. > So the harm of uninitialized locals to the programmer is that he may > make errors that would be caught (as "undefined word") if the locals > were defined later, where they are properly initialized. Sure, but I do not have to remind you that this is Forth: your bullet, gun, and foot. Initialized locals are already provided, and if you prefer to initialize locals, add all of them to the initialized locals list with whatever constant you prefer as the initial value. The problem is already solved. > The harm to the language is that it allows restrictions such as > "only one locals definition in a colon definition" and "no locals > definition inside control structures" to persist. Yes. But OTOH, I'm not in favour of asking Forth implementations to do extra work to support that. So, it's nice to have, but that's all. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-08 15:32 +0000 |
| Subject | Re: uninitialized and implicitly initialized locals |
| Message-ID | <2014Oct8.173212@mips.complang.tuwien.ac.at> |
| In reply to | #33755 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> On the other hand, if someone really wants to create an
>>>uninitialized local I can't see much harm in it.
>>
>> The benefit of defining a local where it is properly initialized is
>> that every read from the local produces a proper value. You cannot
>> read the uninitialized value.
>
>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.
>> Does someone really *want* to create an uninitialized local, or is it
>> just that the programming language does not support what the
>> programmer really wants, and the uninitialized local is a workaround
>> for that? E.g., in Forth-2012 the uninitialized local is a workaround
>> for disallowing to define locals everywhere in a definition.
>
>So that's OK, then. Well, it's not OK, it's all we have at present.
And before, all we had in the standard were initialized locals.
>I'm not going to argue about the programmer convenience of being able
>to declare locals as required, but it's not that easy for the
>implementation and it brings up some tricky issues to do with
>lifetimes. (Which I know you have an answer to in gforth.)
>
>All other things being equal, simple implementations are better than
>complex ones, and locals aren't important enough to justify making
>implementations any more complex than they are at present. IMO, YMMV.
Well, uninitialized locals make Gforth more complex than it is at
present, and they provide exactly zero benefit. Where was your
defense of simple implementations when the addition of uninitialized
locals was being discussed?
>> So the harm of uninitialized locals to the programmer is that he may
>> make errors that would be caught (as "undefined word") if the locals
>> were defined later, where they are properly initialized.
>
>Sure, but I do not have to remind you that this is Forth: your bullet,
>gun, and foot. Initialized locals are already provided, and if you
>prefer to initialize locals, add all of them to the initialized locals
>list with whatever constant you prefer as the initial value. The
>problem is already solved.
No, by defining a local and initializing it to a dummy value before
you know the proper initial value, you will not catch a to-early read
of the local. This problem is not at all solved in Forth-2012.
Anyway, if you think that the existance of initialized locals solves
the problem, what problem is solved by uninitialized locals?
>> The harm to the language is that it allows restrictions such as
>> "only one locals definition in a colon definition" and "no locals
>> definition inside control structures" to persist.
>
>Yes. But OTOH, I'm not in favour of asking Forth implementations to
>do extra work to support that.
But you were in favour of asking Forth implementations to do extra
work to support uninitialized locals? Why?
- 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]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web