Path: utzoo!utgpu!attcan!uunet!husc6!uwvax!rutgers!att!mtuxo!mtgzz!drutx!druhi!grow
From: grow@druhi.ATT.COM (Gary Oblock)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC (was The NeXT problem)
Summary: Special register pair also makes the compiler writers job easier
Message-ID: <3706@druhi.ATT.COM>
Date: 3 Nov 88 23:05:07 GMT
References: <156@gloom.UUCP< <28200218@urbsdc> <4759@pdn.UUCP> <7472@winchester.mips.COM>
Organization: AT&T, Denver, CO
Lines: 66

In article <7472@winchester.mips.COM>, cprice@mips.COM (Charlie Price) writes:
> In article <4759@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes:
> >
> >The 88k does a 32-bit integer multiply in 4 cycles (r3000 takes 13
> >cycles, I believe).  A 32-bit integer divide takes the 88k 39 cycles
> >(r3000 takes 36 cycles, I believe).  Of course, if either of the
> >division operands is negative (signed division opcode), the 88k has to
> >trap to a software routine to finish the division.  In other words,
> >not all RISCs are wimps just because they don't have "complex
> >instructions". 
> >Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida.
> 
> The MIPS R2000 and R3000 have integer multiply/divide instructions,
> but they are unlike the other main CPU instructions.
> The source operands are in general purpose registers and
> the result (64-bit product or 32-bit quotient and 32-bit remainder)
> is written to a special pair of registers named HI and LOW.
> There are instructions (MFHI MFLO) to move from HI and LOW to a
> general register.
> So why do it this (seemingly odd) way?
> 
       :
    Deleted (a bunch of hardware reasons)
> 
> In practice, many things that seem to require multiply instructions
> get turned into some sequence of inline shifts and adds.
> Obviously the compiler makes some sort of decision about which
> is "better" to use.
> -- 
> Charlie Price    cprice@mips.com        (408) 720-1700
> MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA   94086

 Another very good reason to do things this way is that your register
 allocation scheme does not have to deal with allocating  register
 pairs. When register allocation takes place at the intermediate
 code level (e.g. the Stanford U-Code compiling  systems) the
 problem is especially evident. As Fred Chow said about this in
 his section on the limitations of allocating at the intermediate 
 level [page 71; A Portable Machine-Independent Global Optimizer--
 Design and Measurement; Chow, Frederick Chi-Tak; PhD 1984; Stanford
 University]

   The requirements and effects of individual machine instructions
   cannot be taken into account. Such uses of registers arising out
   of instruction selection by code generators are not necessarily
   related to the register allocation decisions. When registers are
   globally allocated by the optimizer, intermixing of registers used
   by the optimizer and registers used by the code generator is not
   possible. ....stuff about redundant copies being introduced...

 In plain old-fashioned register allocators on machines that require
 the use of register pairs for multiplication and division you have
 to treat these registers as special cases. This is done by reserving
 a pair of scratch registers for these operations and/or using clumsy
 heuristics that attempt to keep register pair(s) free when needed for
 these operations.

 All things considerered, allocating registers on a machine with a
 special pair of result registers for multiplication and division
 (i.e. the MIPS) should be much easier and much more effective.

 Gary Oblock -- Compiler consultant to Bell Laboratories -- Denver, CO
                    (303)538-4169 -- att!druhi!grow

 Disclaimer -- I'm pretty sure they'll agree with about this at MIPS.
               But,...  they're not my employers!