[Lightning] Where is lightning used? Suggestions for some changes.

[Paulo César Pereira de Andrade]

  Hi,

  Besides I did not go too far from a hacking mode only in the fork at
https://github.com/pcpa/lightning, I added support for mips32 oabi,
and more recently pretty much any arch/abi setup for arm (well, need
eabi, then it works with arm/thumb2 and soft, softfp and hard, float
abi variants). Also did some ppc hacking and corrected several bugs.

  I understand that the goal of lightning is to be as lightweight as
possible, so, I attempted to be as compatible as possible in the
github fork, and write a new jit based on lightning while at it.

  But I think it could be a good idea to merge both jits, or maybe
create a project with another name for such a merge; the said other
jit currently is embedded in my "hobby" project at
http://code.google.com/p/exl/

  I plan to do a major rewrite of that project at some point, mostly
to be more "jit friendly" but that is another issue.

  What are the main differences of the lightning based jit to
lightning:

o Function arguments are pushed from left to right. This does
  not matter much for i386, and should possibly have been the
  reason it was chosen in the first time. For x86_64 it was worked
  around with jit_prepare_f() and jit_prepare_d(), but that is still
  wrong. For mips and arm it was required a significant hack
  to patch instructions and push arguments from right to left.
  There are pushargr and pushargi variants also.
o Labels are "objects". jit_forward() actually returns a pointer
  that is valid for patching, and there is a jit_link() call to finally
  define the label (maybe jit_bind() or variant would be a better
  name).
o For the sake of simplification, there no jit_namer_l or jit_namei_l,
  only jit_namer and jit_namei, save for unsigned operations with
  the _u modifier and load/store with the _c, _uc, _s, _us, i, _ui,
  and l modifiers. The only exception is truncr_{f,d}_{i,l} as it is
  undefined if the value does not  fit in the given integer type,
  and by using those, in all conditions I know of, it matches the
  equivalent C code for float/double to integer cast/conversion. I
  also dropped the new jit_rintr_* I added to the github fork, as well
  as ceil, floor and round. I think those should put the result in
  a float register, so, for now I just removed it.
o Because there is an optional optimization pass, there are also
  jit_bo{add,sub}* counterparts called jit_bx{add,sub}*, that are
  useful in jump threading to reverse the branch condition.
o The jit code keeps track of live registers. Actually, it needs
  the intermediate representation due to this, so that it can use
  a mask at the start of basic blocks (kind of, just a label), and
  then as it emits jit code it updates registers live state.
o All  float/double operations also have a version with an
  immediate, besides no hardware should support it directly,
  it attempts to do the best decision, by either loading from a
  hashed constants buffer or move the value to integer registers,
  and from the integer registers to float registers.

  Some changes still required:

o Another "extension" I added is that jit_prolog current has no
  options, and jit_prepare has a single flag, currently only useful
  to tell is is building a varargs call. But this still needs rework,
  as it should explicitly specify the "..." point in a function call.
  While this is not much of an issue for printf like calls, it would
  make it work correctly for functions that have prototyped
  float/double arguments before the varargs.
o Simple one that I still did not add, but there is need in my
  usage of the jit is a jit_rsbi. jit_rsbr is kind of pointless.
o There is no instruction combiner, but that is low on priority
  as it could require another IR; most likely not as there are
  plenty of free bitfield possibilities.

  As you see, the lightning base jit is expected to be used by
dynamically typed languages, and to be used to create large
chunks of jit code, like translating a full function to jit, or even
an entire program, like is done in my "toy" language. But I
understand the need for an as lightweight as possible jit, for
example, for a boot loader or something related where it is
not worth to, for example, exchange 1k+ cycles optimizing
branches because they are not in a loop that may be executed
1eN times, for N larger than 5.

  Any comments welcome. I am just trying to make the code
I wrote useful for more people, and also ping'ing the lightning
list as it is silent for quite some time :-)

Thanks,
Paulo