Re: [Qemu-devel] [PATCH 1/8] ARM: Fix decoding of VFP forms of VCVT between float and int/fixed

[Peter Maydell]

On 6 December 2010 16:57, Nathan Froyd <address@hidden> wrote:
> FWIW--and this is not particularly conducive to random insn
> sequences--the approach taken when doing the AltiVec bits was to have
> code that looked like:
>
>  for each insn:
>     for a suitable set of inputs:
>        setup interesting registers (status control registers etc.)
>        load inputs into registers
>        execute
>        record interesting post conditions in file.out

Mmm. The trouble with that is it's more faff per instruction than I'd
like. The nice thing about random instruction sequences is you can
have a config file that says:
VQSHL_reg_a A1 1111 001 u 0 d sz:2 vn:4 vd:4 0100 n 0 m 1 vm:4
VQSHL_reg_b A1 1111 001 u 0 d sz:2 vn:3 0 vd:3 0 0100 n 1 m 1 vm:3 0

and that's all you need to test the VQSHL(reg) forms, and it's basically
the instruction format out of the ARM ARM. (In fact it ought to be a
single line but qemu doesn't correctly UNDEF on the Q==1, lsbit of
Vd/Vn/Vm!=0 case so I am avoiding generating it.)

> You'd get an output file from real hardware and an output file from the
> simulator and then compare them, fixing differences as you go.  The
> actual code included bits to compare the files as well as doing the
> generation.

You could certainly do the 'record/replay file' part; at the moment
what I have does about what I want, though :-).
(I really must get round to writing the README and sticking it
in a public git repo.)

> Of course, the *real* problems are in undefined-behavior land. :)

Heh. We don't even correctly handle "entirely well defined and should
UNDEF" land yet...

-- PMM