On 6 December 2010 16:57, Nathan Froyd <froy...@codesourcery.com> 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
