Article View: comp.arch
Article #11509Re: condition codes
From: Herman Rubin
Date: Sun, 12 May 1991 11:46
Date: Sun, 12 May 1991 11:46
43 lines
2945 bytes
2945 bytes
In article <13011@pt.cs.cmu.edu>, lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:
> In article <12162@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> >Why get rid of condition flags? Other than the condition register, they take
> >up little space, and also they cost essentially nothing. Looking at one or
> >two bits is certainly cheaper than comparing two quantities, even if they are
> >in registers. Overflow and carry are useful.
> The problem with condition flags is the hardware complexity.
> In a simple machine, condition flags can be supported by simple
> hardware. However, suppose that you then build a hot version of that
> simple machine, and try to have some independence between the integer
> unit and the FPU. This attempt will be frustrated by the condition
> codes, because both "independent" units must communicate to these
> bits in a correct order.
> One way out is to dump the condition codes - as several risc machines
> have done. The RS/6000 takes the other way out, and has several sets
> of condition codes.
Why do we have separate integer and floating units, especially without
communication between them? I suggest those who push this horror look
at how difficult conversion between them is. I have already pointed out
that every trigonometic and exponential routine does, in some way,
float/float -> integer, remainder. The integer is also used.
Even putting integerization, addition, and subtraction in floating units
is not the answer. Boolean operations using floats are useful. Packing
and unpacking should be hardware operations. If there is a dichotomy, it
is address/loop versus arithmetic, not integer versus floating. There
have been machines with this feature. But even if one has this, it is
still necessary to have good communication between the units.
The user may not see the use of more sophisticated hardware, but that does
not mean the casual user does not use it. In many situations, on the RS/6000
I would keep two copies of an integer loop variable if it will be used in
floating arithmetic in order to avoid the cost of converting. I wonder if
the compiler writers have thought of that?
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
Technical Details
Message-ID:
<12236@mentor.cc.purdue.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubinReferences:
<12162@mentor.cc.purdue.edu> <13011@pt.cs.cmu.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin From: hrubin@pop.stat.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: condition codes Summary: Communication between units is important Message-ID: <12236@mentor.cc.purdue.edu> Date: 12 May 91 11:46:19 GMT Article-I.D.: mentor.12236 References: <12162@mentor.cc.purdue.edu> <13011@pt.cs.cmu.edu> Sender: news@mentor.cc.purdue.edu Lines: 43