Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!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: Fri, 10 Feb 2012 08:34:58 -0600 Message-ID: <4F352B0B.6040108@SPAM.comp-arch.net> Date: Fri, 10 Feb 2012 06:34:51 -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> <4F341C7B.9070703@SPAM.comp-arch.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 46 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-uv26yl3phrV9WLpNQjqAzifkiR+0EQdhlF312tdBhdvqTfLZF54kkNasXI+Ud68/mh9345Jb+uYLL1g!21xUD/CrsU0YcBWWTEeFp4IqxG1IfBvrhjoDUs0mCSPhfe4Utx7sjXrMC5XP3zI= 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: 4039 Xref: x330-a1.tempe.blueboxinc.net comp.arch:5860 On 2/9/2012 10:58 PM, Stephen Fuld wrote: > On 2/9/2012 11:20 AM, Andy (Super) Glew wrote: >> On 2/8/2012 1:39 PM, Stephen Fuld wrote: >>> On 2/5/2012 3:50 AM, Terje Mathisen wrote: >>>> Stephen Fuld wrote: >>>>> 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. >> 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. > > What I proposed was sort of between the two cases above. Each > instruction that has the bit set can only go to one particular register, > but that register can be different for each instruction. That is, it > isn't always R2, but it is always the register at the next higher number > than the source register number. How does that fit in in terms of > difficulty? Assuming that I have clipped the right spot: What you propose - writing to one register higher than the input - causes me to break out in screaming fits, but, based on what my compiler guy friends in the past have said, can *PROBABLY* be handled. However, I can say with rather high probability that there is probably no existing code in any compiler to do exactly this, and it is quite different from existing register allocation. Thus, my bet is that doing this, while not a theoretical problem, would probably cause the project to "slip by a year", or "require cancelling some other planned compiler features". I.e. at the best it is just another tiresome "simple matter of programming". At the worst, there may be a more fundamental problem that the compiler guys have glossed over. But I must admit that, based on what they have said in the past, they may be able to handle this.