qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/8] ARM: Fix decoding of VFP forms of VCVT betw


From: Nathan Froyd
Subject: Re: [Qemu-devel] [PATCH 1/8] ARM: Fix decoding of VFP forms of VCVT between float and int/fixed
Date: Mon, 6 Dec 2010 11:57:22 -0500
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Dec 06, 2010 at 04:48:25PM +0000, Peter Maydell wrote:
> I'm not sure how well it would fit into being committed to qemu (yet):
> it works as a program where you run half of it on real ARM hardware
> and the other half under qemu (or valgrind) and it compares register
> results after executing instructions by looking at the sigcontext struct
> in a signal handler. Plus there's a perl script to generate random
> instruction set sequences to feed the test program. It could be made
> more automated and independent of having a reference bit of hardware
> but I haven't got round to that yet. (Also since it has utility outside of
> just testing qemu I'm not sure if it really belongs in the qemu repo.)

That does sound a little heavyweight.  Scripting gdb is also a possibility.

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

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.

The output files can be somewhat large, but I'm sure clever engineering
could be applied to make them smaller.

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

-Nathan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]