Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54539 > unrolled thread
| Started by | "HAA" <someone@microsoft.com> |
|---|---|
| First post | 2017-01-30 22:34 +1100 |
| Last post | 2017-02-17 09:09 -0800 |
| Articles | 20 on this page of 42 — 9 participants |
Back to article view | Back to comp.lang.forth
CASEs compared "HAA" <someone@microsoft.com> - 2017-01-30 22:34 +1100
Re: CASEs compared anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-30 15:56 +0000
Re: CASEs compared hughaguilar96@gmail.com - 2017-01-30 09:57 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-01-31 14:26 +1100
Re: CASEs compared hughaguilar96@gmail.com - 2017-01-31 08:12 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-01 11:39 +1100
Re: CASEs compared hughaguilar96@gmail.com - 2017-01-31 22:37 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 12:26 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 16:50 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 18:02 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-02 21:12 +1100
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 13:46 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 17:01 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 12:43 +1100
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:52 -0800
Re: CASEs compared Alex <alex@rivadpm.com> - 2017-02-04 11:10 +0000
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-02 19:57 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 17:05 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-02 21:55 -0500
Re: CASEs compared Mark Wills <markwills1970@gmail.com> - 2017-02-03 02:11 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 10:52 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:38 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 22:08 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 21:40 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 01:16 -0500
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 14:40 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:47 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 22:04 -0500
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 12:39 +1100
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 23:32 -0500
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 22:50 +1100
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 11:07 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-04 08:48 -0800
Re: CASEs compared Mark Wills <markwills1970@gmail.com> - 2017-02-04 10:01 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 16:43 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-04 18:53 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-05 19:12 +1100
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-01-31 14:25 +1100
Re: CASEs compared Elliott Chapin <elliott.chapin@gmail.com> - 2017-02-05 08:25 -0800
Re: CASEs compared Coos Haak <htrofhc@gmail.com> - 2017-02-06 00:42 +0100
Re: CASEs compared jacko <jackokring@gmail.com> - 2017-02-16 17:46 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-17 09:09 -0800
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-03 10:52 -0800 |
| Message-ID | <c8f5c52d-1af6-495c-a2ee-8daa5f5c60bd@googlegroups.com> |
| In reply to | #54607 |
On Friday, February 3, 2017 at 3:11:57 AM UTC-7, Mark Wills wrote:
> On Friday, 3 February 2017 00:57:05 UTC, rickman wrote:
> > On 2/2/2017 5:12 AM, HAA wrote:
> > > hughaguilar96@gmail.com wrote:
> > >> ...
> > >> Since the title of this thread is "CASEs compared," here is a comparison:
> > >>
> > >> : ccc ( n -- )
> > >> case
> > >> 2 of 1 endof
> > >> 3 of 2 endof
> > >> 5 of 3 endof
> > >> 7 of 4 endof
> > >> 11 of 5 endof
> > >> 13 of 6 endof
> > >> 17 of 7 endof
> > >> 19 of 8 endof
> > >> 23 of 9 endof
> > >> 29 of 10 endof
> > >> -1 swap endcase ; ok
> > >>
> > >> 1 ccc . -1 ok
> > >> 2 ccc . 1 ok
> > >> 29 ccc . 10 ok
> > >> 30 ccc . -1 ok
> > >>
> > >> What usually messes me up when using CASE is that the test value is still on the stack
> > >> after the last ENDOF and it has to be left on the stack so ENDCASE can discard it. That
> > >> is why we have a SWAP in there.
> > >
> > > Having the selector left on the stack when all comparisons fail seems natural and
> > > can be useful. What gets in the way is ENDCASE wanting to DROP it for you.
> >
> > I've thought the same thing. Would it make sense for the selector to be
> > held on the return stack so that it can be be accessible and out of the
> > way? Every iteration of "OF" requires an OVER for the comparison, R@
> > isn't really any harder and the ENDCASE still removes it. In fact,
> > rather than have OF remove the selector with a DROP, it can be left on
> > the return stack until jumping to the ENDCASE where it is removed. That
> > saves a bit of code. It would be a change to the standard of course.
> I went through this, too, in 2013. As a result I did this:
>
> http://turboforth.net/resources/case.html
>
> CLF thread here: https://groups.google.com/forum/#!topic/comp.lang.forth/sXcSd_5F6bs%5B1-25%5D
I remember that thread --- 488 posts in a thread must be some kind of record for c.l.f. --- and, of course, nothing accomplished...
Your work-around with DEFAULT: does improve readability. There are a couple of problems though:
1.) It slows down the code by adding yet another branch to be mispredicted.
2.) Sometimes (as HAA pointed out) the selector is needed by the default code section.
Here is another suggestion:
Require the default code section to do something with the selector, or just DROP it. Finish up with:
TRUE ENDCASE
Any value could be used, because ENDCASE is just going to drop it, but TRUE seems at least somewhat intuitive.
Here is your example:
: test
case
1 of 100 endof
2 of 200 endof
3 of 300 endof
drop 999
true endcase
.
;
You might define macros like this:
macro: <case case ;
macro: case> true endcase ;
Then your example looks like this:
: test
<case
1 of 100 endof
2 of 200 endof
3 of 300 endof
drop 999
case>
.
;
I think the reason why Eaker's CASE has this problem, is that it was never reviewed. There was a contest in "Forth Dimensions" for a CASE construct and Eaker's CASE won the contest. Most likely, nobody other than Eaker had looked at it prior to him submitting it to the contest, so it was never reviewed. Then it got adopted because it had won the contest (woo hoo!), and it wasn't reviewed because it was a pseudo-standard already and it was too late to change anything, then it got put in ANS-Forth because it was "common practice."
By comparison, my <SWITCH was posted on comp.lang.forth and was reviewed. Most of the "review" consisted of statements such as this from Rod Pemberton:
"Who exactly will use your <SWITCH construct? It's non-standard and there are other constructs which are widely available. Even you admitted, indirectly, that no one should use it ... [Hugh] admitted he writes crappy code."
This is obviously not useful (although somewhat entertaining).
Much more useful was this from HAA:
"Having the selector left on the stack when all comparisons fail seems natural and can be useful."
This inspired me to rewrite my <SWITCH construct so the default code section (and all of the table entries) are given the selector --- most of the time, they will DROP it because it is unneeded --- but in some cases they do need it, and so there it is!
If HAA hadn't made this comment, I wouldn't have thought of it myself. Then I release the flawed <SWITCH in the novice-package and it becomes a pseudo-standard just like Eaker's CASE after it won the contest, and then it is too late to change anything.
Other than the lack of review, there are other problems with choosing Eaker's CASE because it won a contest in "Forth Dimensions" magazine:
1.) The rules of the contest (all code must be Forth-83) don't apply very well to the real-world, because compiler-writers don't have to use standard code internally, so long as the code they compile is standard --- they routinely do use assembly-language internally to boost speed and to allow them to do things that can't be done in high-level Forth.
2.) There was no money prize in the magazine contest, so it is unlikely that there were very many entries or that any of the programmers made much of an effort --- at the time the contest was promoted in "Forth Dimensions" in the late 1980s, nobody said: "Be sure you do a good job, because your code will get put in the ANS-Forth standard in 1994, and it will still be standard in 2017."
All in all, ANS-Forth killed Forth --- there was a lack of leadership in the Forth community after Charles Moore got kicked out of Forth Inc. --- an idiot was left to steer the Forth wagon, and we went straight into the ditch...
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-03 17:38 -0800 |
| Message-ID | <a1298db4-909a-449b-a576-03d0d8018cc9@googlegroups.com> |
| In reply to | #54610 |
On Friday, February 3, 2017 at 11:52:59 AM UTC-7, hughag...@gmail.com wrote:
> 2.) There was no money prize in the magazine contest, so it is unlikely that there were very many entries or that any of the programmers made much of an effort --- at the time the contest was promoted in "Forth Dimensions" in the late 1980s, nobody said: "Be sure you do a good job, because your code will get put in the ANS-Forth standard in 1994, and it will still be standard in 2017."
I remember when that contest was in "Forth Dimensions" --- I knew what a jump-table was (I learned this from C programming) and I considered entering with something similar to my <SWITCH that I recently wrote --- I waited too long and the deadline passed, so I never entered anything, but I didn't care anyway because the fame of winning a "Forth Dimensions" contest plus $1 will get you a cup of coffee.
The reason why writing the code then was daunting, was that I didn't have the novice-package already available. Now it is the work of one day because:
1.) I already have FIELD available for making structs.
2.) I already have LIST.4TH available for making a list.
3.) I already have BSEARCH available.
4.) I already have { available for declaring local variables (and ANS-Forth actually has local variables, which Forth-83 didn't, although LOCALS| has the parameters backwards).
5.) I already have all the meta-compiling support words available.
6.) I already have experience using this stuff so I don't have to ponder the basic concepts (inheritance, meta-compiling, local variables, etc.).
The novice-package makes ANS-Forth programming easy --- writing everything in raw ANS-Forth as Elizabeth Rather demands makes ANS-Forth programming difficult --- the difference in quality is between <SWITCH as compared to CASE, and really the difference in results is between actually writing code as compared to blowing hot air about your expertise in Forth on c.l.f. and/or the Forth-200x mailing list but never writing any code.
Note that Rickman is now in this thread tossing out suggestions for how people should program in Forth, as if he were an expert in Forth, although he has never written any Forth code at all afaik --- this is not Forth programming, because there is no Forth code being written --- this is just
arrogance, ignorance and hot air (the primary components of most comp.lang.forth discussions).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-03 22:08 -0500 |
| Message-ID | <o73gh1$s01$1@dont-email.me> |
| In reply to | #54612 |
On 2/3/2017 8:38 PM, hughaguilar96@gmail.com wrote: > > Note that Rickman is now in this thread tossing out suggestions for how people should program in Forth, as if he were an expert in Forth, although he has never written any Forth code at all afaik --- this is not Forth programming, because there is no Forth code being written --- this is just > arrogance, ignorance and hot air (the primary components of most comp.lang.forth discussions). Wow, in the other sub-thread he seemed to be fairly friendly, actually discussing the topic with me. This guy is just not on the same planet as the rest of us. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-03 21:40 -0800 |
| Message-ID | <f8f7bcb0-3437-4cbf-be8b-dcd8ef308686@googlegroups.com> |
| In reply to | #54619 |
On Friday, February 3, 2017 at 8:08:59 PM UTC-7, rickman wrote: > On 2/3/2017 8:38 PM, hughaguilar96@gmail.com wrote: > > > > Note that Rickman is now in this thread tossing out suggestions for how people should program in Forth, as if he were an expert in Forth, although he has never written any Forth code at all afaik --- this is not Forth programming, because there is no Forth code being written --- this is just > > arrogance, ignorance and hot air (the primary components of most comp.lang.forth discussions). > > Wow, in the other sub-thread he seemed to be fairly friendly, actually > discussing the topic with me. What makes you think that I want to have a discussion with you? You are not my peer --- you don't program in Forth at all. > This guy is just not on the same planet as the rest of us. All of your arguments quickly devolve into ad hominem attacks such as this --- you're a troll. The point that I was making (for the benefit of any Forth programmers who might be reading this thread) is that a clash between disparate elements of the language using the same resource (the return-stack in this case) is bad design of the language --- this is true of your goofy suggestion with macros hiding >R R@ R> --- this is also true of DO loops (this is why I don't have DO loops in Straight Forth). In the 1970s, the PDP-11 had a severe register shortage. It was necessary for disparate elements of Forth to all use the return-stack, and it was up to the programmer to make sure they didn't clash --- PAD is another example, as are all global variables that can be modified by functions. ANS-Forth was very much 1970s technology. Forth Inc. was just keeping the corpse of Charles Moore's 1970s Forth work warm --- they really weren't noticing the passage of time and the rise of knowledge all around them --- they believed that the decisions Charles Moore made in the 1970s were written in stone and sacrosanct, like the tablets that Moses brought down from Mt. Sinai. My EACH[ ... ]EACH are guilty of hiding >R and R> too. I document this though, and I discourage their use --- I encourage the use of EACH instead, although this is cumbersome without quotations (the rquotations work, but aren't ANS-Forth) --- I only used EACH[ ... ]EACH in my own code because I'm familiar with the pitfall involved so I won't fall in, and it was more convenient for me. I won't have EACH[ ... ]EACH in Straight Forth --- they contain a serious pitfall for the unwary --- a lot of code in the novice-package, such as this, is a kludge that is there because I'm working withing the extremely limited ANS-Forth world. ANS-Forth was 10 or 20 years obsolete in 1994 when it was released --- it was not going to win the race --- it was a dead horse facing backward inside of the gate.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-04 01:16 -0500 |
| Message-ID | <o73rgv$qnl$1@dont-email.me> |
| In reply to | #54621 |
On 2/4/2017 12:40 AM, hughaguilar96@gmail.com wrote: > On Friday, February 3, 2017 at 8:08:59 PM UTC-7, rickman wrote: >> On 2/3/2017 8:38 PM, hughaguilar96@gmail.com wrote: >>> >>> Note that Rickman is now in this thread tossing out suggestions >>> for how people should program in Forth, as if he were an expert >>> in Forth, although he has never written any Forth code at all >>> afaik --- this is not Forth programming, because there is no >>> Forth code being written --- this is just arrogance, ignorance >>> and hot air (the primary components of most comp.lang.forth >>> discussions). >> >> Wow, in the other sub-thread he seemed to be fairly friendly, >> actually discussing the topic with me. > > What makes you think that I want to have a discussion with you? You > are not my peer --- you don't program in Forth at all. Maybe it's the fact that you *are* discussing it with me. >> This guy is just not on the same planet as the rest of us. > > All of your arguments quickly devolve into ad hominem attacks such as > this --- you're a troll. I'm not saying this because I wish to attack you. It has no part in the technical discussion with you. It is a comment about your behavior. Your behavior is something you can't see or at least understand in the terms most people can. I'm not saying your work is crap because you are emotionally dysfunctional. Your work is far above my head, true. But that doesn't change who or what you are. That was my point in referencing your posts in the Wikipedia slide rule talk page. > The point that I was making (for the benefit of any Forth programmers > who might be reading this thread) is that a clash between disparate > elements of the language using the same resource (the return-stack in > this case) is bad design of the language --- this is true of your > goofy suggestion with macros hiding >R R@ R> --- this is also true of > DO loops (this is why I don't have DO loops in Straight Forth). > > In the 1970s, the PDP-11 had a severe register shortage. It was > necessary for disparate elements of Forth to all use the > return-stack, and it was up to the programmer to make sure they > didn't clash --- PAD is another example, as are all global variables > that can be modified by functions. > > ANS-Forth was very much 1970s technology. Forth Inc. was just keeping > the corpse of Charles Moore's 1970s Forth work warm --- they really > weren't noticing the passage of time and the rise of knowledge all > around them --- they believed that the decisions Charles Moore made > in the 1970s were written in stone and sacrosanct, like the tablets > that Moses brought down from Mt. Sinai. > > My EACH[ ... ]EACH are guilty of hiding >R and R> too. I document > this though, and I discourage their use --- I encourage the use of > EACH instead, although this is cumbersome without quotations (the > rquotations work, but aren't ANS-Forth) --- I only used EACH[ ... > ]EACH in my own code because I'm familiar with the pitfall involved > so I won't fall in, and it was more convenient for me. > > I won't have EACH[ ... ]EACH in Straight Forth --- they contain a > serious pitfall for the unwary --- a lot of code in the > novice-package, such as this, is a kludge that is there because I'm > working withing the extremely limited ANS-Forth world. > > ANS-Forth was 10 or 20 years obsolete in 1994 when it was released > --- it was not going to win the race --- it was a dead horse facing > backward inside of the gate. > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-03 14:40 -0500 |
| Message-ID | <o72m7j$hs3$1@dont-email.me> |
| In reply to | #54607 |
On 2/3/2017 5:11 AM, Mark Wills wrote: > On Friday, 3 February 2017 00:57:05 UTC, rickman wrote: >> On 2/2/2017 5:12 AM, HAA wrote: >>> hughaguilar96@gmail.com wrote: >>>> ... >>>> Since the title of this thread is "CASEs compared," here is a comparison: >>>> >>>> : ccc ( n -- ) >>>> case >>>> 2 of 1 endof >>>> 3 of 2 endof >>>> 5 of 3 endof >>>> 7 of 4 endof >>>> 11 of 5 endof >>>> 13 of 6 endof >>>> 17 of 7 endof >>>> 19 of 8 endof >>>> 23 of 9 endof >>>> 29 of 10 endof >>>> -1 swap endcase ; ok >>>> >>>> 1 ccc . -1 ok >>>> 2 ccc . 1 ok >>>> 29 ccc . 10 ok >>>> 30 ccc . -1 ok >>>> >>>> What usually messes me up when using CASE is that the test value is still on the stack >>>> after the last ENDOF and it has to be left on the stack so ENDCASE can discard it. That >>>> is why we have a SWAP in there. >>> >>> Having the selector left on the stack when all comparisons fail seems natural and >>> can be useful. What gets in the way is ENDCASE wanting to DROP it for you. >> >> I've thought the same thing. Would it make sense for the selector to be >> held on the return stack so that it can be be accessible and out of the >> way? Every iteration of "OF" requires an OVER for the comparison, R@ >> isn't really any harder and the ENDCASE still removes it. In fact, >> rather than have OF remove the selector with a DROP, it can be left on >> the return stack until jumping to the ENDCASE where it is removed. That >> saves a bit of code. It would be a change to the standard of course. >> >> -- >> >> Rick C > > I went through this, too, in 2013. As a result I did this: > > http://turboforth.net/resources/case.html > > CLF thread here: https://groups.google.com/forum/#!topic/comp.lang.forth/sXcSd_5F6bs%5B1-25%5D As Hugh points out using default: has one issue, the default code not knowing what the selector value was. Here is an idea. I still like the idea of shoving the selector out of the way on the return stack. So default: can do just that, be a synonym for >R. The default code can access the selector with R@ or invent a word to fetch this so the user doesn't need to remember where the selector is, say selector@. Then the default clause is completed by a word that is a synonym for R>, say ENDDEFAULT or maybe :DEFAULT. No jumps required and ENDCASE continues doing what it has always done with no changes. Any downsides to this? I'm not too sure of the names. Seems like colon has special meanings at the beginning and end of word names. Perhaps something different should be used? There are not many special chars that *don't* have a special meaning in Forth. Here are the special chars I found that have no particular use that might create confusion, % & ^ _ ~. How about the tilde? default~ ~default Or the underscore? default_ _default Or the carat? default^ ^default BTW, when searching for the carat in the 2012 standard, I found the carat in the text is not the same char as the carat in the character list at the footer of the glossary pages. ˆ and ^ ??? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-03 17:47 -0800 |
| Message-ID | <5855065e-0a4a-4e3d-b277-5b3ab28a7b7e@googlegroups.com> |
| In reply to | #54611 |
On Friday, February 3, 2017 at 12:40:13 PM UTC-7, rickman wrote: > Here is an idea. I still like the idea of shoving the selector out of > the way on the return stack. So default: can do just that, be a synonym > for >R. The default code can access the selector with R@ or invent a > word to fetch this so the user doesn't need to remember where the > selector is, say selector@. Then the default clause is completed by a > word that is a synonym for R>, say ENDDEFAULT or maybe :DEFAULT. No > jumps required and ENDCASE continues doing what it has always done with > no changes. > > Any downsides to this? Hiding >R R@ R> inside of macros is a bad idea because EXIT no longer works, and >R R@ R> will generally not work anymore --- this can be documented, but the user will likely not remember; it is just a weird clash that nobody expects (similar to how DO loops clash with >R R@ R> which novices don't expect).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-03 22:04 -0500 |
| Message-ID | <o73g8n$rnq$1@dont-email.me> |
| In reply to | #54615 |
On 2/3/2017 8:47 PM, hughaguilar96@gmail.com wrote: > On Friday, February 3, 2017 at 12:40:13 PM UTC-7, rickman wrote: >> Here is an idea. I still like the idea of shoving the selector out of >> the way on the return stack. So default: can do just that, be a synonym >> for >R. The default code can access the selector with R@ or invent a >> word to fetch this so the user doesn't need to remember where the >> selector is, say selector@. Then the default clause is completed by a >> word that is a synonym for R>, say ENDDEFAULT or maybe :DEFAULT. No >> jumps required and ENDCASE continues doing what it has always done with >> no changes. >> >> Any downsides to this? > > Hiding >R R@ R> inside of macros is a bad idea because EXIT no longer works, and >R R@ R> will generally not work anymore --- this can be documented, but the user will likely not remember; it is just a weird clash that nobody expects (similar to how DO loops clash with >R R@ R> which novices don't expect). And yet we use DO loops, don't we? I see what you say about EXIT, but I don't see that as a show stopper. It only applies to the default case, not the entire case structure. The lack of consistency across the selector defined cases and the default case bugs me, but what about Forth doesn't have quirks? Just as a net is a bunch of holes tied together, Forth is a bunch of quirks tied together by simplicity. CASE is probably just fine the way it is. I haven't seen any training material on this in a long time, but it should cover the oddity of the default case clearly. Once you get past that, Bob's your uncle. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-04 12:39 +1100 |
| Message-ID | <o73bhd$h72$1@gioia.aioe.org> |
| In reply to | #54598 |
rickman wrote:
> On 2/2/2017 5:12 AM, HAA wrote:
> > ...
> > Having the selector left on the stack when all comparisons fail seems natural and
> > can be useful. What gets in the way is ENDCASE wanting to DROP it for you.
>
> I've thought the same thing. Would it make sense for the selector to be
> held on the return stack so that it can be be accessible and out of the
> way? Every iteration of "OF" requires an OVER for the comparison, R@
> isn't really any harder and the ENDCASE still removes it. In fact,
> rather than have OF remove the selector with a DROP, it can be left on
> the return stack until jumping to the ENDCASE where it is removed. That
> saves a bit of code. It would be a change to the standard of course.
See below. Newer versions of VFX may do better but in general it's faster to test
against items on the data stack than return stack. For native code optimizers DROP
can disappear - unlike R> DROP. Hence the expected code saving never materialized.
: CASE1 0 ; immediate
: OF1 postpone over postpone = postpone if postpone drop ; immediate
: ENDCASE1 postpone drop begin ?dup while postpone then repeat ; immediate
: CASE2 postpone >r 0 ; immediate
: OF2 postpone r@ postpone = postpone if ; immediate
: ENDCASE2 begin ?dup while postpone then repeat postpone r> postpone drop ; immediate
: ENDOF postpone else ; immediate
: test1 case1
1 of1 8 endof
2 of1 9 endof
3 of1 10 endof
dup
endcase1 ;
: test2 case2
1 of2 8 endof
2 of2 9 endof
3 of2 10 endof
r@
endcase2 ;
see test1
TEST1
( 004AB110 83FB01 ) CMP EBX, 01
( 004AB113 0F850A000000 ) JNZ/NE 004AB123
( 004AB119 BB08000000 ) MOV EBX, 00000008
( 004AB11E E926000000 ) JMP 004AB149
( 004AB123 83FB02 ) CMP EBX, 02
( 004AB126 0F850A000000 ) JNZ/NE 004AB136
( 004AB12C BB09000000 ) MOV EBX, 00000009
( 004AB131 E913000000 ) JMP 004AB149
( 004AB136 83FB03 ) CMP EBX, 03
( 004AB139 0F850A000000 ) JNZ/NE 004AB149
( 004AB13F BB0A000000 ) MOV EBX, 0000000A
( 004AB144 E900000000 ) JMP 004AB149
( 004AB149 C3 ) NEXT,
( 58 bytes, 13 instructions )
ok
see test2
TEST2
( 004AB170 53 ) PUSH EBX
( 004AB171 8B1C24 ) MOV EBX, [ESP]
( 004AB174 83FB01 ) CMP EBX, 01
( 004AB177 8B5D00 ) MOV EBX, [EBP]
( 004AB17A 8D6D04 ) LEA EBP, [EBP+04]
( 004AB17D 0F8510000000 ) JNZ/NE 004AB193
( 004AB183 8D6DFC ) LEA EBP, [EBP+-04]
( 004AB186 895D00 ) MOV [EBP], EBX
( 004AB189 BB08000000 ) MOV EBX, 00000008
( 004AB18E E943000000 ) JMP 004AB1D6
( 004AB193 8B1424 ) MOV EDX, [ESP]
( 004AB196 83FA02 ) CMP EDX, 02
( 004AB199 0F8510000000 ) JNZ/NE 004AB1AF
( 004AB19F 8D6DFC ) LEA EBP, [EBP+-04]
( 004AB1A2 895D00 ) MOV [EBP], EBX
( 004AB1A5 BB09000000 ) MOV EBX, 00000009
( 004AB1AA E927000000 ) JMP 004AB1D6
( 004AB1AF 8B1424 ) MOV EDX, [ESP]
( 004AB1B2 83FA03 ) CMP EDX, 03
( 004AB1B5 0F8510000000 ) JNZ/NE 004AB1CB
( 004AB1BB 8D6DFC ) LEA EBP, [EBP+-04]
( 004AB1BE 895D00 ) MOV [EBP], EBX
( 004AB1C1 BB0A000000 ) MOV EBX, 0000000A
( 004AB1C6 E90B000000 ) JMP 004AB1D6
( 004AB1CB 8B1424 ) MOV EDX, [ESP]
( 004AB1CE 8D6DFC ) LEA EBP, [EBP+-04]
( 004AB1D1 895D00 ) MOV [EBP], EBX
( 004AB1D4 8BDA ) MOV EBX, EDX
( 004AB1D6 8D642404 ) LEA ESP, [ESP+04]
( 004AB1DA C3 ) NEXT,
( 107 bytes, 30 instructions )
ok
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-03 23:32 -0500 |
| Message-ID | <o73ldb$ava$1@dont-email.me> |
| In reply to | #54613 |
On 2/3/2017 8:39 PM, HAA wrote: > rickman wrote: >> On 2/2/2017 5:12 AM, HAA wrote: >>> ... >>> Having the selector left on the stack when all comparisons fail seems natural and >>> can be useful. What gets in the way is ENDCASE wanting to DROP it for you. >> >> I've thought the same thing. Would it make sense for the selector to be >> held on the return stack so that it can be be accessible and out of the >> way? Every iteration of "OF" requires an OVER for the comparison, R@ >> isn't really any harder and the ENDCASE still removes it. In fact, >> rather than have OF remove the selector with a DROP, it can be left on >> the return stack until jumping to the ENDCASE where it is removed. That >> saves a bit of code. It would be a change to the standard of course. > > See below. Newer versions of VFX may do better but in general it's faster to test > against items on the data stack than return stack. For native code optimizers DROP > can disappear - unlike R> DROP. Hence the expected code saving never materialized. > > : CASE1 0 ; immediate > : OF1 postpone over postpone = postpone if postpone drop ; immediate > : ENDCASE1 postpone drop begin ?dup while postpone then repeat ; immediate > > : CASE2 postpone >r 0 ; immediate > : OF2 postpone r@ postpone = postpone if ; immediate > : ENDCASE2 begin ?dup while postpone then repeat postpone r> postpone drop ; immediate > > : ENDOF postpone else ; immediate > > : test1 case1 > 1 of1 8 endof > 2 of1 9 endof > 3 of1 10 endof > dup > endcase1 ; > > : test2 case2 > 1 of2 8 endof > 2 of2 9 endof > 3 of2 10 endof > r@ > endcase2 ; > > see test1 > TEST1 > ( 004AB110 83FB01 ) CMP EBX, 01 > ( 004AB113 0F850A000000 ) JNZ/NE 004AB123 > ( 004AB119 BB08000000 ) MOV EBX, 00000008 > ( 004AB11E E926000000 ) JMP 004AB149 > ( 004AB123 83FB02 ) CMP EBX, 02 > ( 004AB126 0F850A000000 ) JNZ/NE 004AB136 > ( 004AB12C BB09000000 ) MOV EBX, 00000009 > ( 004AB131 E913000000 ) JMP 004AB149 > ( 004AB136 83FB03 ) CMP EBX, 03 > ( 004AB139 0F850A000000 ) JNZ/NE 004AB149 > ( 004AB13F BB0A000000 ) MOV EBX, 0000000A > ( 004AB144 E900000000 ) JMP 004AB149 > ( 004AB149 C3 ) NEXT, > ( 58 bytes, 13 instructions ) > ok > > see test2 > TEST2 > ( 004AB170 53 ) PUSH EBX > ( 004AB171 8B1C24 ) MOV EBX, [ESP] > ( 004AB174 83FB01 ) CMP EBX, 01 > ( 004AB177 8B5D00 ) MOV EBX, [EBP] > ( 004AB17A 8D6D04 ) LEA EBP, [EBP+04] > ( 004AB17D 0F8510000000 ) JNZ/NE 004AB193 > ( 004AB183 8D6DFC ) LEA EBP, [EBP+-04] > ( 004AB186 895D00 ) MOV [EBP], EBX > ( 004AB189 BB08000000 ) MOV EBX, 00000008 > ( 004AB18E E943000000 ) JMP 004AB1D6 > ( 004AB193 8B1424 ) MOV EDX, [ESP] > ( 004AB196 83FA02 ) CMP EDX, 02 > ( 004AB199 0F8510000000 ) JNZ/NE 004AB1AF > ( 004AB19F 8D6DFC ) LEA EBP, [EBP+-04] > ( 004AB1A2 895D00 ) MOV [EBP], EBX > ( 004AB1A5 BB09000000 ) MOV EBX, 00000009 > ( 004AB1AA E927000000 ) JMP 004AB1D6 > ( 004AB1AF 8B1424 ) MOV EDX, [ESP] > ( 004AB1B2 83FA03 ) CMP EDX, 03 > ( 004AB1B5 0F8510000000 ) JNZ/NE 004AB1CB > ( 004AB1BB 8D6DFC ) LEA EBP, [EBP+-04] > ( 004AB1BE 895D00 ) MOV [EBP], EBX > ( 004AB1C1 BB0A000000 ) MOV EBX, 0000000A > ( 004AB1C6 E90B000000 ) JMP 004AB1D6 > ( 004AB1CB 8B1424 ) MOV EDX, [ESP] > ( 004AB1CE 8D6DFC ) LEA EBP, [EBP+-04] > ( 004AB1D1 895D00 ) MOV [EBP], EBX > ( 004AB1D4 8BDA ) MOV EBX, EDX > ( 004AB1D6 8D642404 ) LEA ESP, [ESP+04] > ( 004AB1DA C3 ) NEXT, > ( 107 bytes, 30 instructions ) > ok Without wading through the assembly code, I can't see how the simple changes you made would cause such large changes in the assembly code. The part that recurs three times is one Forth word shorter. The two parts that are used once are one Forth word longer. Any ideas? Looks to me that VFX is doing some great optimizations for TEST1 while doing virtually nothing for TEST2. What this is showing is not the difference in the two examples, but the difference in how VFX treats them. I would try these cases under Win32Forth but I can't seem to figure out how to disassemble a forth definition. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-04 22:50 +1100 |
| Message-ID | <o74f31$1sao$1@gioia.aioe.org> |
| In reply to | #54620 |
rickman wrote: > ... > Without wading through the assembly code, I can't see how the simple > changes you made would cause such large changes in the assembly code. > The part that recurs three times is one Forth word shorter. The two > parts that are used once are one Forth word longer. Any ideas? > > Looks to me that VFX is doing some great optimizations for TEST1 while > doing virtually nothing for TEST2. What this is showing is not the > difference in the two examples, but the difference in how VFX treats them. You would have to ask MPE but my guess is once you spill to the return stack there's less interest to optimize as the return stack is supposed to be for temporary storage. > I would try these cases under Win32Forth but I can't seem to figure out > how to disassemble a forth definition. Win32F is non-optimized threaded code. SEE xxx is as good as you will get. LOCATE xxx can be used to show the source code of individual words.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-04 11:07 -0500 |
| Message-ID | <o74u57$68a$1@dont-email.me> |
| In reply to | #54625 |
On 2/4/2017 6:50 AM, HAA wrote: > rickman wrote: >> ... >> Without wading through the assembly code, I can't see how the simple >> changes you made would cause such large changes in the assembly code. >> The part that recurs three times is one Forth word shorter. The two >> parts that are used once are one Forth word longer. Any ideas? >> >> Looks to me that VFX is doing some great optimizations for TEST1 while >> doing virtually nothing for TEST2. What this is showing is not the >> difference in the two examples, but the difference in how VFX treats them. > > You would have to ask MPE but my guess is once you spill to the return stack > there's less interest to optimize as the return stack is supposed to be for > temporary storage. "Less interest"??? Optimization is optimization. Look at the assembly generated. It is horribly suboptimal with moves from the stack cache register to the data stack, then move from the return stack to register, registers getting clobbered and reloaded a few instructions later. This isn't code looking for optimization, this is just poor code generation. >> I would try these cases under Win32Forth but I can't seem to figure out >> how to disassemble a forth definition. > > Win32F is non-optimized threaded code. SEE xxx is as good as you will get. > LOCATE xxx can be used to show the source code of individual words. > > > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-04 08:48 -0800 |
| Message-ID | <74ca1e8d-dc03-44ef-a9b9-1137841b1e20@googlegroups.com> |
| In reply to | #54627 |
On Saturday, February 4, 2017 at 9:07:45 AM UTC-7, rickman wrote: > On 2/4/2017 6:50 AM, HAA wrote: > > You would have to ask MPE but my guess is once you spill to the return stack > > there's less interest to optimize as the return stack is supposed to be for > > temporary storage. > > "Less interest"??? Optimization is optimization. Look at the assembly > generated. It is horribly suboptimal with moves from the stack cache > register to the data stack, then move from the return stack to register, > registers getting clobbered and reloaded a few instructions later. This > isn't code looking for optimization, this is just poor code generation. This is what FAST-SWITCH> generates: see fff FFF ( 004E37A0 8BD3 ) MOV EDX, EBX ( 004E37A2 83C3FE ) ADD EBX, -02 ( 004E37A5 83FB15 ) CMP EBX, 15 ( 004E37A8 8D6DFC ) LEA EBP, [EBP+-04] ( 004E37AB 895500 ) MOV [EBP], EDX ( 004E37AE 0F860C000000 ) JBE/NA 004E37C0 ( 004E37B4 8B5D00 ) MOV EBX, [EBP] ( 004E37B7 8D6D04 ) LEA EBP, [EBP+04] ( 004E37BA E839FFFFFF ) CALL 004E36F8 ( 004E37BF C3 ) NEXT, ( 004E37C0 C1E302 ) SHL EBX, 02 ( 004E37C3 8B932C374E00 ) MOV EDX, [EBX+004E372C] ( 004E37C9 8B5D00 ) MOV EBX, [EBP] ( 004E37CC 8D6D04 ) LEA EBP, [EBP+04] ( 004E37CF FFD2 ) CALL EDX ( 004E37D1 C3 ) NEXT, ( 50 bytes, 16 instructions ) ok It looks reasonable to me. Rickman describes VFX code generation as: "horribly suboptimal." Maybe it depends upon the programmer though. This is comparable to what I would hand-write, although I would not use CALL followed by RET but would use JMP instead. This new version does ROVER because it is leaving the selector on the data-stack for use by the table entries or the default code --- they typically DROP it though. The old version did ROT because it didn't keep the selector. Interestingly, ROT results in much more efficient code than ROVER (a macro for 2 PICK) --- in the old days of non-optimized Forth, ROT typically generated very slow code, especially on a processor with a lack of registers available for holding the three values while moving them around --- now however, ROT is efficient and DUP OVER or ROVER are less efficient. This is the old version: see sss SSS ( 004E35E0 83C3FE ) ADD EBX, -02 ( 004E35E3 83FB1B ) CMP EBX, 1B ( 004E35E6 0F860C000000 ) JBE/NA 004E35F8 ( 004E35EC 8B5D00 ) MOV EBX, [EBP] ( 004E35EF 8D6D04 ) LEA EBP, [EBP+04] ( 004E35F2 E849FFFFFF ) CALL 004E3540 ( 004E35F7 C3 ) NEXT, ( 004E35F8 C1E302 ) SHL EBX, 02 ( 004E35FB 8B934C354E00 ) MOV EDX, [EBX+004E354C] ( 004E3601 8B5D00 ) MOV EBX, [EBP] ( 004E3604 8D6D04 ) LEA EBP, [EBP+04] ( 004E3607 FFD2 ) CALL EDX ( 004E3609 C3 ) NEXT, ( 42 bytes, 13 instructions ) ok
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-02-04 10:01 -0800 |
| Message-ID | <53324943-ecc6-4511-96dd-06eb3ee89b17@googlegroups.com> |
| In reply to | #54629 |
I think VFX generates good code.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-04 16:43 -0500 |
| Message-ID | <o75hqq$bku$1@dont-email.me> |
| In reply to | #54630 |
On 2/4/2017 1:01 PM, Mark Wills wrote: > I think VFX generates good code. That's a very blanket statement. Can't VFX generate good code sometimes and bad code other times? Did you look at the example above? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-04 18:53 -0800 |
| Message-ID | <bbf25fee-ba20-4298-8f22-6e1286d4506c@googlegroups.com> |
| In reply to | #54630 |
On Saturday, February 4, 2017 at 11:01:58 AM UTC-7, Mark Wills wrote: > I think VFX generates good code. Yes, it is quite good. Use of the return-stack or locals doesn't work out so well though. VFX isn't 64-bit though --- I should get pretty good speed with Straight Forth just because it is 64-bit and has 16 registers --- the 32-bit x86 is 20th century technology. BTW: I said before that the new FAST-SWITCH> used ROVER rather than ROT --- that is actually SLOW-SWITCH> that does that --- FAST-SWITCH> is bigger because it now has a DUP that it didn't previously have. Providing the selector adds some cost because most of the time it is going to get dropped anyway --- but we are talking about a few clock cycles --- the convenience of having the selector in those cases when it is needed makes it worthwhile. This is the code generated by FAST-SWITCH> and SLOW-SWITCH> respectively: see fff FFF ( 004E37A0 8BD3 ) MOV EDX, EBX ( 004E37A2 83C3FE ) ADD EBX, -02 ( 004E37A5 83FB15 ) CMP EBX, 15 ( 004E37A8 8D6DFC ) LEA EBP, [EBP+-04] ( 004E37AB 895500 ) MOV [EBP], EDX ( 004E37AE 0F860C000000 ) JBE/NA 004E37C0 ( 004E37B4 8B5D00 ) MOV EBX, [EBP] ( 004E37B7 8D6D04 ) LEA EBP, [EBP+04] ( 004E37BA E839FFFFFF ) CALL 004E36F8 ( 004E37BF C3 ) NEXT, ( 004E37C0 C1E302 ) SHL EBX, 02 ( 004E37C3 8B932C374E00 ) MOV EDX, [EBX+004E372C] ( 004E37C9 8B5D00 ) MOV EBX, [EBP] ( 004E37CC 8D6D04 ) LEA EBP, [EBP+04] ( 004E37CF FFD2 ) CALL EDX ( 004E37D1 C3 ) NEXT, ( 50 bytes, 16 instructions ) ok see sss SSS ( 004E3A70 8D6DEC ) LEA EBP, [EBP+-14] ( 004E3A73 C7450008000000 ) MOV DWord Ptr [EBP], 00000008 ( 004E3A7A 895D04 ) MOV [EBP+04], EBX ( 004E3A7D C7450809000000 ) MOV DWord Ptr [EBP+08], 00000009 ( 004E3A84 C7450C083A4E00 ) MOV DWord Ptr [EBP+0C], 004E3A08 ( 004E3A8B 895D10 ) MOV [EBP+10], EBX ( 004E3A8E BBE0324E00 ) MOV EBX, 004E32E0 ( 004E3A93 E888A6FFFF ) CALL 004DE120 BSEARCH ( 004E3A98 85DB ) TEST EBX, EBX ( 004E3A9A 8B5D00 ) MOV EBX, [EBP] ( 004E3A9D 8D6D04 ) LEA EBP, [EBP+04] ( 004E3AA0 0F850C000000 ) JNZ/NE 004E3AB2 ( 004E3AA6 8B5D00 ) MOV EBX, [EBP] ( 004E3AA9 8D6D04 ) LEA EBP, [EBP+04] ( 004E3AAC E823FFFFFF ) CALL 004E39D4 ( 004E3AB1 C3 ) NEXT, ( 004E3AB2 8B5304 ) MOV EDX, [EBX+04] ( 004E3AB5 8B5D00 ) MOV EBX, [EBP] ( 004E3AB8 8D6D04 ) LEA EBP, [EBP+04] ( 004E3ABB FFD2 ) CALL EDX ( 004E3ABD C3 ) NEXT, ( 78 bytes, 21 instructions ) ok see bsearch BSEARCH ( 004DE120 8D6DFC ) LEA EBP, [EBP+-04] ( 004DE123 895D00 ) MOV [EBP], EBX ( 004DE126 BB00000000 ) MOV EBX, 00000000 ( 004DE12B E85464F2FF06000000 ) CALL 00404584 MAKELVS #args = 0006, #locals = 0000 cells ( 004DE134 8D6DFC ) LEA EBP, [EBP+-04] ( 004DE137 895D00 ) MOV [EBP], EBX ( 004DE13A 8B5F18 ) MOV EBX, [EDI+18] ( 004DE13D 90 ) NOP ( 004DE13E 90 ) NOP ( 004DE13F 90 ) NOP ( 004DE140 85DB ) TEST EBX, EBX ( 004DE142 750B ) JNZ/NE 004DE14F ( 004DE144 8B5D00 ) MOV EBX, [EBP] ( 004DE147 8D6D04 ) LEA EBP, [EBP+04] ( 004DE14A E96D000000 ) JMP 004DE1BC ( 004DE14F 8BD3 ) MOV EDX, EBX ( 004DE151 D1FB ) SAR EBX, 1 ( 004DE153 8B4F10 ) MOV ECX, [EDI+10] ( 004DE156 0FAFCB ) IMUL ECX, EBX ( 004DE159 034F1C ) ADD ECX, [EDI+1C] ( 004DE15C 894F08 ) MOV [EDI+08], ECX ( 004DE15F 8D6DF4 ) LEA EBP, [EBP+-0C] ( 004DE162 8B4F14 ) MOV ECX, [EDI+14] ( 004DE165 894D00 ) MOV [EBP], ECX ( 004DE168 895D04 ) MOV [EBP+04], EBX ( 004DE16B 895508 ) MOV [EBP+08], EDX ( 004DE16E 8B5F08 ) MOV EBX, [EDI+08] ( 004DE171 FF570C ) CALL [EDI+0C] ( 004DE174 85DB ) TEST EBX, EBX ( 004DE176 0F8514000000 ) JNZ/NE 004DE190 ( 004DE17C BBFFFFFFFF ) MOV EBX, FFFFFFFF ( 004DE181 8B5708 ) MOV EDX, [EDI+08] ( 004DE184 895504 ) MOV [EBP+04], EDX ( 004DE187 8D6D04 ) LEA EBP, [EBP+04] ( 004DE18A 8B6704 ) MOV ESP, [EDI+04] ( 004DE18D 8B3F ) MOV EDI, 0 [EDI] ( 004DE18F C3 ) NEXT, ( 004DE190 85DB ) TEST EBX, EBX ( 004DE192 8B5D00 ) MOV EBX, [EBP] ( 004DE195 8D6D04 ) LEA EBP, [EBP+04] ( 004DE198 0F8D08000000 ) JNL/GE 004DE1A6 ( 004DE19E 8D6D04 ) LEA EBP, [EBP+04] ( 004DE1A1 E914000000 ) JMP 004DE1BA ( 004DE1A6 8B5710 ) MOV EDX, [EDI+10] ( 004DE1A9 035708 ) ADD EDX, [EDI+08] ( 004DE1AC 89571C ) MOV [EDI+1C], EDX ( 004DE1AF 43 ) INC EBX ( 004DE1B0 8B5500 ) MOV EDX, [EBP] ( 004DE1B3 2BD3 ) SUB EDX, EBX ( 004DE1B5 8BDA ) MOV EBX, EDX ( 004DE1B7 8D6D04 ) LEA EBP, [EBP+04] ( 004DE1BA EB84 ) JMP 004DE140 ( 004DE1BC 8D6DF8 ) LEA EBP, [EBP+-08] ( 004DE1BF 8B571C ) MOV EDX, [EDI+1C] ( 004DE1C2 895500 ) MOV [EBP], EDX ( 004DE1C5 895D04 ) MOV [EBP+04], EBX ( 004DE1C8 BB00000000 ) MOV EBX, 00000000 ( 004DE1CD 8B6704 ) MOV ESP, [EDI+04] ( 004DE1D0 8B3F ) MOV EDI, 0 [EDI] ( 004DE1D2 C3 ) NEXT, ( 179 bytes, 60 instructions ) ok
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-05 19:12 +1100 |
| Message-ID | <o76mn7$103o$1@gioia.aioe.org> |
| In reply to | #54627 |
rickman wrote: > On 2/4/2017 6:50 AM, HAA wrote: > > rickman wrote: > >> ... > >> Without wading through the assembly code, I can't see how the simple > >> changes you made would cause such large changes in the assembly code. > >> The part that recurs three times is one Forth word shorter. The two > >> parts that are used once are one Forth word longer. Any ideas? > >> > >> Looks to me that VFX is doing some great optimizations for TEST1 while > >> doing virtually nothing for TEST2. What this is showing is not the > >> difference in the two examples, but the difference in how VFX treats them. > > > > You would have to ask MPE but my guess is once you spill to the return stack > > there's less interest to optimize as the return stack is supposed to be for > > temporary storage. > > "Less interest"??? Optimization is optimization. Look at the assembly > generated. It is horribly suboptimal with moves from the stack cache > register to the data stack, then move from the return stack to register, > registers getting clobbered and reloaded a few instructions later. This > isn't code looking for optimization, this is just poor code generation. I'm not MPE. You asked for an 'idea' as to what might be going on and I gave it. If it's facts you want ask MPE keeping in mind the disassembly represents an old version of VFX as I stated.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-31 14:25 +1100 |
| Message-ID | <o6p01m$3sb$1@gioia.aioe.org> |
| In reply to | #54545 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >hughaguilar96@gmail.com wrote: > >> ... > >> CASE has to be nested IF statements though, which is horribly inefficient. > > > >Perhaps not. Below is some test code for VFX. It compares IF/ELSE Case with > >SWITCH from FD 20/3. The former gave me 10x better speed. > ... > This is not the kind of thing Hugh Aguilar has in mind. Also, the > point of VanNorman's SWITCH is not performance, but being able to add > more key-action pairs later; that's why he uses a linked list. All true but my purpose was to post code as near to the traditional uses of an IF/ELSE Case. Hugh may have special needs that rule out Eaker but to assert it is 'horribly inefficient' is a statement which at the very least needs qualification. > And guess what: If we care about performance, we do. We just don't do > it by inventing another CASE/SWITCH construct, but we use EXECUTE and > an xt table; or maybe the whole thing is reorganized: There are reasons why that isn't used in practice. To get the speed you have to be presented with an ideal situation that rarely occurs, you have to go out of your way to use it, the economics don't stack up when a few labels/cases are present (which is most of the time), and the thing that's finally executed will often take more time than the switch itself. > In Gforth 0.7, we have an intelligent COMPILE, that uses Eaker's CASE > to decide how to compile each word type. In the development version, > each word has a field that says how the word is COMPILE,d, and > COMPILE, now does something like > > : compile, ( xt -- ) > xt>compile, @ execute ; > > And I think that's why there was never much demand for something > beyond Eaker's CASE. If there are so many OFs that the linear search > becomes inefficient, idiomatic Forth programming stops putting all > that code in a single word. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Elliott Chapin <elliott.chapin@gmail.com> |
|---|---|
| Date | 2017-02-05 08:25 -0800 |
| Message-ID | <7b0fea22-50d8-45c1-aa6d-8e9470711297@googlegroups.com> |
| In reply to | #54539 |
Where is Mitch Bradley's CASE extension code?
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-02-06 00:42 +0100 |
| Message-ID | <1eutzbj0ih5l6$.r9g1ddj27ts8$.dlg@40tude.net> |
| In reply to | #54640 |
Op Sun, 5 Feb 2017 08:25:54 -0800 (PST) schreef Elliott Chapin: > Where is Mitch Bradley's CASE extension code? http://www.forth.org/fd/contents.html look for issue 20-3 page 19: A Forth Switchblade groet Coos
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | comp.lang.forth
csiph-web