🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11509

Re: condition codes

#11509
From: Herman Rubin
Date: Sun, 12 May 1991 11:46
43 lines
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!hrubin
References: <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