Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!hplabs!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: Condition Codes in General Registers Message-ID: <1631@winchester.mips.COM> Date: 19 Feb 88 07:40:11 GMT References: <191@telesoft.UUCP> <1556@gumby.mips.COM> <208@telesoft.UUCP> <7405@apple.UUCP> <6834@sol.ARPA> <3798@lll-winken.llnl.gov> <184@granite.dec.com> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 58 In article <184@granite.dec.com> jmd@granite.UUCP (John Danskin) writes: >I am a fan of condition codes in general registers because I would like to be.. >I would like to say as well that it seems like a waste to put the condition >codes in GENERAL registers. The little suckers are only one or two bits >depending on how you set things up, and it would be relatively inexpensive >to have a whole bank of special condition code registers. ... Unfortunately, this probably is not a good idea, for both hardware and software reasons: In a heavily-pipeline machine (like any of the current RISCs), the output of an ALU cycle isn't actually written back into a register into one or more cycles later. Nevertheless, the output must be available as input to the next cycle, without a delay cycle, or else you take a large performance hit. Hence, such machines use "register bypass networks" to let a cycle grab the previous cycle's output on the way to the registers. If you want to have a single condition code whose use doesn't delay a branch, you have to bypass the condition code also, and of course, that takes more hardware, which must be slightly different than the register bypassing network. Compilers MUST deal with the CC, and that has been a notable pain on some machines, as it is a register that doesn't act like any other register. If you want to have multiple condition codes: An optimizer must allocate and deallocate them, i.e., it better be doing live/dead analysis, perhaps keeping a set safe across functions calls, etc, i.e., everything it needs to do for registers! BTW, the better global optimizers tend to be space-intensive, with at least some effect from the number of registers. Having a bunch of CCs that need to be tracked is NOT doing a favor for the compiler writer. Your instruction set needs to be able to address the CC register file, which thus ends up being a bunch of (different) sorts of registers, and of course, they need their own bypass network. In any case, in most normal code, the lifetime of most condition-code settings is very short, i.e., you very seldom have more than one or two lying around. When you do, if you have a machine with enough registers, you just use the registers, and all is well. Thus, having "weird" registers not only doesn't help anybody much, but it's more likely to get in the way of both hardware and software. I can't remember the references offhand, but Bill Wulf had an article many years ago, I think in CACM, that described the attributres of architectures that were good/bad for optimizers, and I think Steve Johnson had a similar article, w.r.t. the C language. It's been a long time; the latter may have been a Bell Labs internal memo. Moral: it's REAL easy for hardware to do "favors" for software that can be done without. Separate CCs are good examples. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086