Re: [patch][rfa] Add ltu,leu,gtu,geu support for unsigned modes

[Doug Evans <dje@transmeta.com>]

Dave Brolley writes:
 > That's why I was led to believe that this 
 > support was appropriate.

I'm not faulting you for thinking that.
We need to reach a decision about Umodes and more rigidly enforce it.
Mea culpa.

I propose we set a direction of removing them entirely.

One catch, to me anyway, is that I much prefer thinking of
registers (esp. pc) as unsigned quantities.
Thus an additional step might be to define SI as unsigned
when it appears in C.  At the semantic level it is neither signed
nor unsigned, but C doesn't really have a way of understanding that,
and that might cause confusion.  Whether it'd be a more palatable
confusion than having both SI and USI I dunno.

 > It may be excessive, but one could also argue that it's 
 > more complete to support Umodes.

Depends on how you look at things.
To a cpu, a 32 bit register is a 32 bit register.
Ditto for when the 32 bit quantity lives in memory.
It's only in how it is subsequently used or interpreted that
signedness might come into play.
When signedness comes into play on the chip, it's explicitly
specified in the operation, _not_ in the data.
Ergo from this perspective Umodes don't belong in .cpu files.
And I think this is the perspective we must use (when writing
.cpu files anyway).

 > (if (lt (zext UDI op1) (zext UDI op2 ))(set op3 op1 ))
 > 
 > works and it's hard to explain to the customer why ltu doesn't accept 
 > umodes while lt does.

Well, it's easy to explain.  No claim is made that one's eyes won't roll.
Is LTUDI LT concatenated with UDI or LTU concatenated with DI?

 > >@item UQI,UHI,USI,UDI
 > >Unsigned versions of QI,HI,SI,DI.
 > >
 > >These modes do not appear in semantic RTL.  Instead, the RTL function
 > >specifies the signedness of its operands where necessary.
 > > [...]
 >
 > Perhaps this can help me convince the customer.

I think if you explain the above reasoning that will also help.