[Top][All Lists]

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

Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc w

From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings]
Date: Fri, 6 Aug 2010 14:33:22 -0300
User-agent: SquirrelMail/1.4.19

Paulo César Pereira de Andrade wrote:
> [snip]
>   This test case version may be a bit harder to compile as now it
> depends on binutils devel, as I added a stripped down version of
> the dissassembler I wrote for my language/virtual machine (initially
> based on the GNU Smalltalk one).
>   The new test attempts to detect stack corruption, and when finding
> unexpected results, disassembles an as localized as it can figure
> block of code, but it may be just disassembling the side effects,
> that is, past the problem...
>   It is also not passing doubles (and unsigned longs) by value, but
> using pointers and static storage. Just to avoid the risk of getting
> the stack corrupted (later another test case can be written to test
> consistency on function arguments).
>   Based on output, the failures in i686 should be only one, related
> to load/store of single byte with certain jit registers. And the
> failures on x86_64 should be only sign extension when loading a
> negative 8/16/32 bit integer and storing in a 64 bit one.
>   The test case is basically about memory load/store, so, major
> missing features are check of usage of multiple floating point
> registers and check of moving data from register to register.

  I just did some minor review in the lightning code in my vm to
use latest git snapshot, and now I have split:

#define JIT_FIXME               defined(__x86_64__)

to an extra:
#define JIT_ldf_std_WORKS       !defined(__x86_64__)

and added the related extra load/store tests to lightning-test.c.
The problem actually should be only ld*f/st*d (at least ld*d/st*f
appears to not show any side effects in my language tests), and
the test new cases show some noise because it does not set back
"sensible" values to the etypes_t float fields before doing the
second test.


Attachment: lightning-test.c
Description: Text Data

reply via email to

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