Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!198.186.194.247.MISMATCH!news-out.readnews.com!transit3.readnews.com!nx02.iad01.newshosting.com!newshosting.com!216.196.98.142.MISMATCH!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 09 Feb 2012 19:16:41 -0600 Message-ID: <4F341C7B.9070703@SPAM.comp-arch.net> Date: Thu, 09 Feb 2012 11:20:27 -0800 From: "Andy (Super) Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 Newsgroups: comp.arch Subject: Re: M68k add to memory is not a mistake any more References: <4F2CD4FA.4050004@SPAM.comp-arch.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 49 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-7CzsnGX0U6MbGVV64HQO5za7gXUpH46dZlGD0/1SNeHTBu0nMA5d9Oxmdpi0F2EKHG1Ik6Yze3uLYxV!LxxPFwvksizwj0tOu0bobN9pVs/8drAYguO/NFqxz7eVMw0qi8bcSzykBPSrndM= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4028 Xref: x330-a1.tempe.blueboxinc.net comp.arch:5851 On 2/8/2012 1:39 PM, Stephen Fuld wrote: > On 2/5/2012 3:50 AM, Terje Mathisen wrote: >> Stephen Fuld wrote: >>> On 2/4/2012 11:53 AM, Terje Mathisen wrote: >>>> I'm not convinced 3-operand is a net loss at all, even if most of the >>>> obvious wins are in really short sequences of complicated >>>> latency-critical operations. >>> >>> A potential compromise would be to have a two operand instruction >>> format, but with an additional single bit field. Upon decoding, the >>> value of this field is added to the register number (from the >>> instruction istelf, not the contents of the specified register) to give >>> the destination register. Thus, if the value of the field is zero, the >>> instruction is a traditional two operand instruction. If the bit is set, >>> then the destination is one register "higher" than the source and you >>> have preserved the source register's contents. >>> >>> I think this would gain much (but probably not all) of the value of >>> three operand instructions, but with only a single bit instead of >>> however many are needed for a full register specification. >> >> Sorry, but I think you're probably wrong here: >> >> Such an idea could work well for asm hackers, doing very careful manual >> register allocation for any critical inner loop, but compilers seems to >> prefer much more orthogonal registers. > > Thanks, Terje. I am not a compiler guy. I realized, of course, that this > sort of breaks orthogonality, but didn't realize it would be that big a > deal for the compiler to deal with. The academic received knowledge has been that compilers do much better with regular, orthogonal, register files. However, I have also learned, in person communication from some of the best compiler writers in the world, that it is not that hard to deal with irregular instruction sets. They say things like "it's just another color to deal with". But that these techniques are not compilers 101, not typically taught in a school, even at graduate level, unless you are specializing in exactly this. I took a course from Michael Wolfe, the "superoptimizing supcomiler for supercomputers guy", who said the same thing, although not so forcefully. They do emphasize that they dislike totally fixed register bindings, such as "Instruction FOO can only read from reg r1 and write to reg r2". But as long as each operand can come from or go to a few places, say 2 or 4, they say they can usually schedule without too much wasted motion.