jans@mako.UUCP (Jan Steinman) (11/01/84)
I've been writing assembly code for over seven years, and I've noticed two, widely differing philosophies on CPU condition code flag usage. The "Flaggers", such as the 68000 family, try to keep the flags full of useful information at all times by affecting as many of them as makes sense with each operation, while the "Ask-For-Its", such as the 8080 and NS32000 families, make you beg for every bit. I can see arguments for each side, (as obviously Motorola did when they split with orthogonality in limiting address registers' ability to flip flags) but lean toward "Flaggers" as exhibiting preferable behavior. What do others prefer? Why did these machines go their separate ways? Any insiders care to comment? (The onions expressed are carefully perfumed to avoid offending anyone's sensibilities and have nothing to do with the onions in any cafeteria in any institution where I may, or may not, have previously eaten or am presently eating.) (Let the lawyers munch on that a while.) -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
bcase@uiucdcs.UUCP (11/06/84)
[]
Re: condition code setting and whether to set all the time or only
when explicitly asked for (i.e. TST in PDP-11s).
There is a paper, whose author I cannot presently recall, entitled
(hmm, I guess I cannot even recall that precisely) "The PDP-11, an
examply of how NOT to do condition codes." In this paper, the author
shows that about 90% of the time, the effort spent by the hardware
to set condition codes is wasted. Most of the time that a program
wants to use the condition codes for conditional branching, the program
uses an explicit TST instruction anyway! There is a related discussion
taken up in "Hardware/Softare tradeoffs for performance" by Hennessey
et. al. (am not even sure of that title) where the authors take the
stand that condition codes are, in general, a bad idea. I just happen
to agree, except that they can be convenient quite often. In a machine
that I have built (a RISC-like machine), there is one condition code bit
which is explicitly set to reflect a selected condition and can then
either be implicitly named by a conditional branch ("branch condition
code bit true", "branch condition code bit false") or gated onto one
of the ALU source busses so that the condition can be directly converted
to data. This, I think, efficiently satisfies most needs since a program
can be interested in at most one *condition* (as opposed to condition
code bits such as negative, overflow, zero, ...) (a *condition* is a
combination of condition code bits) at a time.
bcasewayne@bambi.UUCP (Wayne Wilner) (11/08/84)
The author of the paper on DEC's bad condition codes is Prof. Robert Russell, U. New Hampshire. It appeared in the proceedings of the Nth Annual SIGARCH Workshop on Computer Architecture, where N is about 5. The location of the workshop was Palo Alto.
aynang@pur-ee.UUCP (Aynang) (11/08/84)
The paper "Hardware/Software Tradeoffs fro Increased Performance" is written by J.L. Hennessy, N. Jouppi, F. Baskett, and T.R. Gross. It appeared in the Proc. SIGARCH/SIGPLAN Symp. on Architectural Support for Programming Languages and Operating Systems, sponsored by ACM, held at Polo Alto, ca, on March, 1982. Also, the MIPS project developed at Stanford University does not use any EXPLICIT status register as other computers do. Instead, it uses 34-bit ALU register to manipulate 32-bit data operations. Both carry and overflow condition code are implicitly implied by bit 32 and 33 in the ALU register. AND THIS WORK. However, this prevent the users from setting these flags. MIPS does not offer neither explicit PC nor stack ( and hence no SP ).