[Dotgnu-libjit] Sign/zero extension on byte/short native call return values [was: How to check the value of a boolean variable].

[GARCIA DE SORIA LUCENA, JUAN JESUS]

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