[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Dotgnu-libjit] Sign/zero extension on byte/short native call return val
From: |
GARCIA DE SORIA LUCENA, JUAN JESUS |
Subject: |
[Dotgnu-libjit] Sign/zero extension on byte/short native call return values [was: How to check the value of a boolean variable]. |
Date: |
Wed, 20 Aug 2008 11:17:51 +0200 |
Hi everyone.
I've been looking at the problem I have. I've seen the coalescing of all
"int"-types as the same "source" types (differing only in sign) in
jit_insn_convert(). I've seen also that integer opcodes are defined only for
INT/UINT sized operands.
I don't know where to go to look for libjit design decisions, but these items
seem to suggest that:
* libjit saves whoever ports it to a new architecture from implementing
byte/short opcodes by promoting those operand types to the matching (in the
signedness sense) int type.
* libjit saves itself a lot of up-conversions (sign/zero extensions when the
small types are passed to int opcodes) by using the convention that these types
are actually stored sign/zero extended in int-sized registers, so that
up-conversions are trivial (just use more bits of the register).
If the above considerations are correct, then the problem happens when libjit
has to interface with native (non-libjit-compiled) functions that return small
integers and that don't follow the same convention about extending the
zero/sign. The 32 bit register (EAX in my case) containing the result has not
been extended and the upper bytes contain garbage, invalidating the second
assumption above.
I considered making jit_insn_convert() actually extend the zero/sign on
up-conversion by treating byte/short source types as specific cases, which
would provide safety for all cases, but which would probably force a lot of
dummy extensions that won't actually be needed unless byte and short opcodes
for comparisons, additions, etc. were implemented too. I gave up because
implementing the changes was tedious, error-prone, and I probably would have
needed to extend the jit_convert_info_t to have more opcodes. I was not sure
whether, when extending byte to int, CVT(JIT_OP_TRUNC_{S,U}BYTE, {,u}int) is
enough, or a sequence of CVT(JIT_OP_TRUNC_{S,U}BYTE, {,u}byte),
CVT(JIT_OP_COPY_{,U}INT, {,u}int) is actually required.
The other option, the one I've implemented in the attached patch, is to always
extend the values returned from jit_insn_call_native() when the returned type
is {S,U}BYTE or {,U}SHORT. I've tested it and it works with my test case,
producing this machine code:
02250045 push edi
02250046 call
FOLArithmeticObjectWrapperBase<FOLContinuousCurve<double,double>,double,FOLArithmeticContinuousCurveWrapper<double,double,double,FOLStandardArithmeticOperations,2000000000>,FOLStandardArithmeticOperations,2000000000>::JITCompiler<FOLContinuousCurveEvaluator<FOLContinuousCurve<double,double>
>,1,0>::test_adaptor (4A3C70h)
0225004B movzx eax,al
0225004E add esp,1Ch
02250051 or eax,eax
02250053 je 0225007B
The solution is simpler, keeps the benefits of the two assumptions above, and
seems to work as intended.
What I'm not sure about is whether short integers that are passed by reference
to native functions may suffer the same problem. I guess not, since from-memory
loads happening afterwards should extend the value, but I've not checked it at
all.
As a more general question, I'd like to know how the coordination of
development happens for libjit. Is this list the only development forum? Are
there any other coordination or planning means, like an IRC channel? How does
one become an active participant in the development of libjit?
Is there any kind of design documentation available about how libjit is
supposed to work? In case there isn't, who are the reference people for getting
that information?
The AUTHORS file lists Rhys Weatherley only. But the listed e-mail address
lives in the southern-storm.com.au domain, that seems to be down, and the last
contribution by that person seems to have happened on January 2006, if the
ChangeLog file is faithful to reality.
Any help/guide will be appreciated.
Thanks in advance,
Juan Jesús.
> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of GARCIA DE SORIA LUCENA, JUAN JESUS
> Sent: Thursday, August 14, 2008 9:56
> To: address@hidden
> Cc: MARTINEZ PLAZA, IVAN; address@hidden
> Subject: RE: [Dotgnu-libjit] How to check the value of a
> boolean variable.
>
>
> Hi, Klaus.
>
>
> > -----Original Message-----
> > From: address@hidden [mailto:address@hidden Did you
> ckeck with a
> > jit_type_sbyte or jit_type_byte return type?
>
> I've just changed my native function prototype to:
>
> static unsigned char EXP_STATIC_METHOD
> test_adaptor(void* stack_vp);
>
> Where EXP_STATIC_METHOD is #defined as "__cdecl".
>
> And the signature that I use when declaring the native function:
>
> jit_type_t ta_signature; // Signature for the test adaptor.
> jit_type_t ta_params[1];
>
> ta_params[0] = jit_type_void_ptr; // A pointer to the stack.
>
> ta_signature = jit_type_create_signature(jit_abi_cdecl,
> jit_type_ubyte, ta_params, 1, 1);
>
> When debugging with MSVC, with a breakpoint at the native
> function, I can go up the stack and see this libjit-generated
> code (sorry for the C++ template spam):
>
> 02250045 push edi
> 02250046 call
> FOLArithmeticObjectWrapperBase<FOLContinuousCurve<double,doubl
> e>,double,FOLArithmeticContinuousCurveWrapper<double,double,do
> uble,FOLStandardArithmeticOperations,2000000000>,FOLStandardAr
> ithmeticOperations,2000000000>::JITCompiler<FOLContinuousCurve
> Evaluator<FOLContinuousCurve<double,double>
> >,1,0>::test_adaptor (4A3C70h)
> 0225004B add esp,1Ch
> 0225004E or eax,eax
> 02250050 je 02250078
>
> So the behaviour is the same in this case.
>
> It seems that either the call to jit_insn_convert() in
> jit_insn_branch_if_not() at jit-insn.c:3936 either doesn't
> receive the proper conversion destination type, or doesn't
> end performing the datatype extension...
>
>
> > I don't know to which type jit_type_sys_bool is mapped.
>
> From the macros used in jit-type.c, I'd swear it to be ubyte:
>
> DECLARE_TAGGED(sys_bool, ubyte_def, JIT_TYPETAG_SYS_BOOL);
>
>
>
> Best regards, and thanks in advance,
>
> Juan Jesús.
>
>
> _______________________________________________
> Dotgnu-libjit mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/dotgnu-libjit
>
> * Mensaje analizado y protegido, tecnologia antivirus
> www.trendmicro.es *
>
native-call-small-return-type-extend.patch
Description: native-call-small-return-type-extend.patch