Whither UCMPH?

[Carl S. Gutekunst]

In article <14394 at comp.vuw.ac.nz> jonathan at comp.vuw.ac.nz (Jonathan) writes:
>Pyramid's machine architecture includes a variety of integer
>compare instructions for signed and unsigned compares:
>
> [table deleted]
>
>UCMPH (opcode 67) is conspicuous by its absence.

Speaking as a datacommie who knows zilch about architecture or compilers....

I'd say the other non-integer compares are conspicuous by their presense.
Everything besides the int compare is unnecessary, to wit:

- For variables in registers, you (the compiler writer) can make sure that the
  value is *always* an int. This costs you nothing. So all compares to non-
  floating values in registers always use cmpw and ucmpw.

- If it's not in a register, you very likely have to move it into a register
  before you can compare to it. So you use the apropriate movzbw, cvtbw, or
  whatever. And now you're comparing ints again.

>Is it elsewhere?  [[we don't actually have an up-to-date assembler manual....

It's not in my assembler manual either.

>Wasn't it Wirth who said that RISC should stand for Regular Instruction Set
>Computer :-) ?

Since the Pyramid 90x and 9000 CPUs are microcoded, they accumulated quite a
lot of garbage that someone thought was a "pretty neat idea" at the time. :-)
Seriously, I believe there was some turmoil on the part of the designers as to
what to add and what to leave out; having microcode allowed the machine to be
designed more quickly, but created the illusion that choices weren't critical.
This is what makes architectures crufty and difficult to scale; backwards com-
patability dictates that you drag along instructions that you don't use any
more. 

I'd like to see some of these squeezed out in the new machines, but like I
said, I do X.25, not CPUs.... 

<csg>