Re: [Lightning] About 32 and 64 bits registers

[Paulo César Pereira de Andrade]

Paulo César Pereira de Andrade wrote:

  Hi Paolo,

  I understand that you should be very busy. I may also in the near
future become busy enough to rarely work on my hobby programming
language project, where I intend to use lightning as a jit backend.

  I am trying to resist the temptation of adding a copy of lightning
to my project, where I would be free to hack around, to attempt to
keep upstream in sync with any changes. But I understand that you
would be better with high quality, final patches, not requests for
comments :-)

  Either way, my most recent "tests" appear to work very well in
i686, but fail badly on x86_64. The last ones are:

o varargs.tst
  Test calls to sprintf and sscanf, with 10 to 20 arguments, mixing
  integers and floats. This needs a patch for x86_64 that I tried to
  start a detailed, step by step series of patches, as it requires
  passing parameters on registers, and on stack. The patch uses the
  System V abi, and is fully compatible with code generated by gcc
  on Linux at least.
o args.tst
  Tests calls to jit functions, passing all kinds of basic type
  arguments, and checks that arguments are "properly" received, e.g.
  pass a int8 with a negative value, and ensures the function receives
  a properly sign extended argument, with the expected value, and so
  on. I think I need the x86_64 patch before working on correcting the
  issues found in x86_64.
o branch.tst
  Tests all branch combinations. Currently only using JIT_R0, JIT_R1
  (JIT_R2 on operations that clobber JIT_R0 for printing error messages,
  example is jit_boadd{r,i}), JIT_FPR0 and JIT_FPR1. Again, this showed
  all kinds of problems in x86_64. Too bad I use calls to printf directly
  from jit to report the errors...

  These are the last ones I wrote, but I plan to write more tests.

  Back to the issue of 32/64 bits registers, I think the proper solution
probably would be more like:

  jit_movi_i vs jit_movi_l vs jit_movi_ui vs jit_movi_ul

  Now that the _{u,}l versions exist, maybe it would not be wise to
remove them, but just make them an alias, but, the 'i' should be
understood as (i)mmediate, and the ui as (u)nsigned (i)mmediate.
Same thing would apply to branches, e.g. jit_bltr_i would mean
jit_branch_if_less_than(label, register, immediate)

>>   How is it expected to handle proper sign/zero extension when there
>> are no named 8/16/32/64 bit registers, that is, there is no JIT_R0c,
>> JIT_R0s, JIT_R0i and/or JIT_R0l.
>>
>>   This has a nasty side effect that some operations must be sign/zero
>> extended, for example, when loading data from a memory location. But
>> then, some operations become somewhat hard to explain, for example:
>>
>>   jit_bltr_i LABEL, JIT_R0, IMMEDIATE
>>
>> this should be understood as "treated JIT_R0 value as 32 bits, but
>> signed extend it, as well as immediate" ? or even better, only sign
>> extend to 64 bits if there is no 32 bits equivalent operation.
>> But to do an "optimized" operation, it must ensure that JIT_R0 is
>> actually holding a 64 bits value.
>>
>>   Or another example:
>>
>>   jit_movi_i JIT_R0 IMMEDIATE
>>
>> this should be just an alias to jit_movi_l on 64 bits, or, better
>> saying, should be more like:
>>
>>   jit_movi_i JIT_R0 (cast_to_int_32)IMMEDIATE
>
>   I am adding what is for now an RFC about this issue, and the start
> of another set of patches for x86_64. This shows one option of
> creating jit_namex_{ri,r} "helper macros", that would basically
> become jit_namei_* on 32 bits, and jit_namel_* on 64 bits, and
> this way, ensuring the value in a register is properly sign/zero
> extended.
>
>   This is only an issue when _ASM_SAFETY is defined, and, in some
> points is caused by patch6 in the "Updates for x86_64" email, but
> if did not add the changes in patch6, it would not have gone this
> far :-), The problem is that patch6 changes some of core-64.h to
> "map" JIT_R* to 64 bit registers instead of 32 bit ones, otherwise,
> it is a chicken and egg problem, where now it fails some assertions
> due to using a 64 bits register on 32 bit operations, and before
> it would fail due to using a 32 bits register on 64 bits operations.

Thanks,
Paulo