Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!IBM.COM!JBS
From: JBS@IBM.COM
Newsgroups: comp.arch
Subject: bizarre instructions
Message-ID: <9102260512.AA10814@ucbvax.Berkeley.EDU>
Date: 26 Feb 91 05:12:10 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 32


         In discussing what a compiler should do with i8=j4*k4 where
i8 is integer*8, j4,k4 are integer*4, Herman Rubin says
I have never seen any language description in which the type of the result
in a replacement statement affected what operation is performed.

         I would not propose this.  I would propose defining the type of
an integer*4 x integer*4 multiplication to be integer*8.  Then the right
thing will be done whether i8 is 8 bytes or 4 bytes long.
         Several people have discussed various instruction sequences with
the assumption that all fixed point instructions take the same amount of
time.  While on many machines most fixed point instructions are 1 cycle,
this is generally not true of fixed point multiply and especially not
true of fixed point divide.  Thus a compiler which uses 2 divides for
         iq=ia/ib
         iq=mod(ia,ib)
may be wasting the equivalent of 20+ typical fixed point instructions.
In fact if you know the compiler will do this the sequence
         iq=ia/ib
         ir=ia-iq*ib
will be much faster on many machines.  The 11 instruction pop subroutine
used a divide with remainder.  On many machines this instruction will be
considerably slower than the other 10 combined.  If one is doing many
divides by the same integer p it will often pay to replace them with
multiplies by some "magic constant" based on the binary representation
of 1/p.
         Regarding wrongheaded instructions I believe there are numerous
examples where a complicated instruction was implemented in such a way
that a sequence of simpler instructions doing exactly the same thing
would execute faster.  Of course this may be an implementation problem
rather than an architecture problem.
                          James B. Shearer


Brought to you by Super Global Mega Corp .com