Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: condition codes
Message-ID: <13011@pt.cs.cmu.edu>
Date: 12 May 91 05:19:16 GMT
References: <12162@mentor.cc.purdue.edu>
Organization: Carnegie Mellon
Lines: 20

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.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Robotics Institute