Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!goblin1!goblin.stu.neva.ru!news.mi.ras.ru!spln!extra.newsguy.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Helmar Wodtke Newsgroups: comp.lang.forth Subject: Re: How about helping optimization in language? Date: Wed, 28 Mar 2012 05:03:37 -0700 (PDT) Organization: http://groups.google.com Lines: 62 Message-ID: <19362301.798.1332936217796.JavaMail.geo-discussion-forums@yneo2> References: <30126800.1344.1332858395156.JavaMail.geo-discussion-forums@ynnk21> <582295.182.1332861133595.JavaMail.geo-discussion-forums@ynko6> <8543639.1665.1332866775484.JavaMail.geo-discussion-forums@vbyj26> <9650506.536.1332872991736.JavaMail.geo-discussion-forums@vblo18> NNTP-Posting-Host: 62.158.112.15 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1332936218 25930 127.0.0.1 (28 Mar 2012 12:03:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 28 Mar 2012 12:03:38 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=62.158.112.15; posting-account=nibe3QoAAADcYL8fC0WC6vCas4By1Xgn User-Agent: G2/1.0 X-Received-Bytes: 4503 Xref: csiph.com comp.lang.forth:10718 Am Mittwoch, 28. M=E4rz 2012 10:02:53 UTC+2 schrieb Andrew Haley: > Helmar Wodtke wrote: > > Am Dienstag, 27. M?rz 2012 19:27:48 UTC+2 schrieb Andrew Haley: > >> Helmar Wodtke wrote: > >> >=20 > >> > The basic question was: how to find two of three values on stack > >> > that are bigger than the smallest one. > >> >=20 > >> > ( a b c -- d e -- d, e are the maximums values of a b c) > >> > : 2of3 2dup max >r min max r> ; > >> >=20 > >> > This would be my "thumb simplification" of the thing. > >>=20 > >> That is a very pretty solution. > >=20 > > The sequence "max >r min" is not really pretty. It is nice - but it > > depends on implementation of the Forth system if this is a good > > solution. >=20 > How so? =20 If you have flow analysis and the system takes MAX as "2dup < if nip else d= rop then" it can optimize it if you have just the same question a bit later= . If not, it depends if this is a good solution - maybe the implementations o= f MAX and MIN (because they are that simple) are better than introduction o= f IF/THEN flow control and/or shuffling the stack. > > This is about what I was talking about >R and R> - a lot depends on > > interpretation of the system. If the system has a register left, why > > should >R be a stack in this small thing? It could go to the > > register as long as I keep it stable ;) Well, some flow control > > words would disturb the optimizations probably. >=20 > Why does it matter? Are you so concerned with microoptimization that > this might cause you to lose sleep? Good question ;) But the smaller pieces you program and the more you introd= uce things that are not really needed, the slower the combination of the sm= all things. A sequence like "2dup max >r min" does two compares where the l= ast one is not needed one could think in theory. > Is the compiler is using data flow analysis then the return stack > moves won't do much, and probably won't generate any code at all. If > not, then there will be some traffic. But a good piece of advice is > "don't sweat the small stuff", and this surely is small stuff. Forth > isn't assembly language. Mhm, regarding the return stack: either - as someone else wrote - use direc= tly local variables (compiler thinks for you where to store it) or for such= a use as local storage of data from the program do not mix it with the rea= l return stack. I.E. you can have an own "scratch stack". The real return stack is usually not very interesting for an application pr= ogrammer. Except you are doing manipulations of it for some purpose - but i= n this case you are bound to the model of how your Forth works internally r= egarding the return stack. Some very simple optimizations (like "tail call = optimizations" or to inline small fragments of code) are much more complica= ted to implement because of mixing "data"/"flow control" informations on th= e "return" stack. Regards, -Helmar