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

[Paulo César Pereira de Andrade]

Paolo Bonzini wrote:

>>    The good thing was that all bits were already inplace, was only
>> needing to define the proper macros. Also, note that jit_extr_d_f
>> requires SSE2 or newer, but jit_extr_f_d is plain SSE.
>
> Thanks, I'll do it for SPARC and PPC too.

  Ok. I am attaching an updated patch where it does not change
fp-common.h, as that is not required for i386.

>>    Now the remaining x86_64 problem is sign extending 64 bit values,
>> (I will try to figure out how to correct it later, should be easier
>> than the floats solution) so, if #define'ing sign_extend to 0, it
>> will pass all tests.
>
> It's likely using mov or movz incorrectly instead of movs.

  I am trying to understand the opcodes generation, learning about
rex prefixes, etc. But I found out that it doesn't even get to the
failure point if compiled with -D_ASM_SAFETY=1, i.e. runtime errors
like:

lightning-test.c:385: 32-bit register required
Abortado

  Still trying to understand instruction formats, but the problem
appears to happen at load time, i.e. (without _ASM_SAFETY defined):

V0 V1 V2 R0 F0
lightning-test.c:241:xi_c: cl: ffffff81 ffffff81
          0x775170      movabs $0x778840,%rbx
          0x77517a      movsbl 0x8(%rbx),%r13d     <<<1>>>
          0x77517f      mov    %r13d,0xa(%rbx)
          0x775183      mov    %r13d,0x10(%rbx)
          0x775187      mov    %r13,0x18(%rbx)

shouldn't that be %r13 instead of %r13d?

  I also corrected the warn macro. Use ,## instead of ,#
(duh, I implemented it in the preprocessor of my language, and still
falled for that in a simple test case :-)

  BTW, I am planning to write a small&simple assembler for lightning,
instead of doing the very hard task of extending the current sample
test case to cover more cases, example could be something like:

.c ident value
.s otherident othervalue
label:
    ldr_c %r0, %v0
    movi_p %r1, value

etc, probably very hackish, but that would allow writing test
cases easily, that would work as input for that assembler, and
make it easier to test all possible code generation combinations
(should not be that large, as it would test only distinct
instructions and possibly unwanted side effects).

[I want to use lightning to generate code for my vm, and so far to
me it is the better option, just needs some teaking :-)]

> Paolo

Thanks,
Paulo

lightning-test.c.gz
Description: GNU Zip compressed data

0001-Implement-jit_extr_f_d-and-jit_extr_d_f-for-x86_64.patch
Description: Text Data

0002-Correct-macro-expansion-of-warn-macro-in-ldst-test.patch
Description: Text Data