Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Jul 03, 2014 at 09:30:05PM -0700, Richard Henderson wrote:

> > Another one is probably not worth bothering - PERR, CTPOP, CTLZ, UNPKBx and PKxB
> > don't accept literal argument.  For one thing, as(1) won't let you generate
> > those, so it would have to be explicit
> > 	.long 0x70001620
> > instead of
> > 	perr $0,0,$0
> > On DS10 it gives SIGILL; under qemu it succeeds.  Trivial to fix, anyway,
> > if we care about that (if (islit) goto invalid_opc; in 1C.030..1C.037).
> 
> Is it just 030..037, or everything under opcode 1C?

No, just those.

> Sadly, V4 of the handbook doesn't mention *anything* about not actually
> allowing literals for any of these insns.

It does - compare 4.13.1 (4-155, page 225) with 4.13.2 (two pages later).
The former has
	MINxxx		Ra.rq,Rb.rq,Rc.wq		! Operate format
			Ra.rq,#b.ib,Rc.wq
	MINxxx		Ra.rq,Rb.rq,Rc.wq		! Operate format
			Ra.rq,#b.ib,Rc.wq
The latter -
	PERR		Ra.rq,Rb.rq,Rc.wq		! Operate format

And yes, PERR with bit 12 set will give invalid instruction trap, while e.g.
MINSB8 won't.  The Real Intrudprize Kwality(tm) of technical writing, that,
but the information is, indeed, there.  Verified on UP1000, which has 0x307
for feature bits, so all this stuff is really in hardware, not emulated.

OPC1C is a mess - that's one place on alpha where decoder needs more than
upper 6 bits to determine the format of instruction.  Most of those guys
are Operate (with an extra twist being that some don't take literals),
but FTOIS and FTOIT are F-P, and only approximately so (its source refers
to integer register, destination to floating point one).  Note that
function field is in bits 5--11 for Operate and 5--15 for F-P ;-/  Bit
11 allows to discriminate between those, since FTOIS and FTOIT have function
0x70 and 0x78 resp, while everything else has it lower than 0x40.  Hell
knows how that mess had come to be...

Anyway, the situation with literals in OPC1C:
0, 1 (SEXT[BW]).  Work, rejected by as(1).
0x30--0x37.  Invalid instruction trap, as(1) (correctly) refuses to produce
those.
0x38--0x3f.  Work, accepted by as(1).
0x70, 0x78.  Those are F-P, no literals for them.

SEXTB/SEXTW are missing ARG_OPRL form in binutils opcodes/alpha-opc.c; probably
not worth bothering...