[Lightning] Status of patches for x86_64 (and some for i386)

[Paulo César Pereira de Andrade]

  Hi,

  The current code in http://github.com/pcpa/lightning now pass all
tests in http://code.google.com/p/exl/source/browse/trunk/check/lightning
for i386 and x86_64, but that does not mean it has no bugs lurking.
  The tests should be still extended for better checking of register
clobbers; in i386/x86_64 I am almost sure there may still exist
some clobber of JIT_R0 (%eax/%rax) at least, that was not
properly tested.
  Also, there may still exist some bad short jump encoded. Usually
off by one, and/or caused by some code emitting 1-3 different amount
of bytes. These sometimes can go for a long time undetected, so,
I think it should be a good idea to use the logic I added to correct
illegal instructions in x86_64 for {eq,ne}r_{f,d} and i386 for truncr_{f,d},
where it does not directly emit the jump displacement, but uses a
jit_local_state label field to store the jump address, and then patches
the displacement; this also makes the code more readable.
  I should rebase the repository soon, to merge some patches, and
make them easier to read and review, so that it is easier to
pull patches to mainstream; no need to save the history for
posterity :-)
Another significant change should be to check for 32 bit immediate
values in the "higher level", and not down there in i386/asm.h and
i386/asm-64.h, as usage of JIT_REXTMP down there is dangerous...

  Now more about ideas, it has been proposed to use inline
functions. This may have issues on where and with which
compiler one wants to compile code using lightning. Either way,
at worst some do { } while (0) could be used, to create local
variables, and/or add extra jit_local_state information.

  SSE* support should be added to i386, and SSE>2 as well
for both, but somehow have runtime information to allow
choosing what can be emitted. It is jit code after all :-)
Also, x87 interface should somehow exist for x86_64, as
it is part of the ABI (but only for long double).

  Some kind of register allocation logic. A function without
arguments should be able to use registers that are used
for arguments, or, it should not be required to push/pop
%eax, %edx, %ecx on instructions that only operate
on those if it is known that the registers are free for
that operation.

  Basic, and not so basic, optimizations, most times on
immediate values. For example, convert "addi %r0 1"
to use the inc instruction, multiply/divide by power of 2
converted to the equivalent bit shift, etc.

  Some more handy operations to easier implementation
of dynamically typed languages that coerce numeric types,
example (only brain storm):
o lhmul rl rh O1 O2
  sets rl to low and rh to high bits of O1 * O2
o lhadd/lhsub rl rh O1 O2
  sets rl to low and rh to high (carry/borrow) bits of
  O1 +/- O2
o divrem rq rr O1 O2
  sets rq to quotient and rr to remainder of O1 / O2
even better if accepting a label to jump on overflow/carry;
but these probably would be cpu dependent and only
available as some kind of extension interface, where the
programmer would acknowledge it is cpu specific, by
including an extra header or adding extra definitions.
In this case it is practicity vs portability, and for most,
not an excuse for some minor programming time for
two alternate path, that would save an unimaginable
amount of cpu cicles...

  Particularly for the language I am working, and plan
to use lightning for jit, it would be desirable to:
o have complex double (using SSE) support, and following
  the ABI
o the examples above on handling overflow/carry
o access to the full register set
o anything the processor can aid on morphing
  object types, but that rarely change type, but
  require several indirect jumps, or jump tables

Thanks,
Paulo