[Lightning] RFC: Proposal for lightning 2.0

[Paulo César Pereira de Andrade]

  Hi,

  I have been declared gnu lightning maintainer :-)

  I plan to merge code from another "lightning like" jit I wrote, and
any feedback
is welcome.

  Visible changes:

* No automatic initialization, need to call:
  jit_state_t *_jit = jit_new_state();
  jit_init();
  If using a name other than _jit, need to call functions as
  _jit_xyz(var, args)
  as there are macros in the format:
  #define jit_xyz(args) _jit_xyz(_jit, args)
  or use some #define magic.
* Arguments to functions are pushed left to right.
* Remove "i" and "l" suffix, exceptions are argument passing, return value,
  load/store, and float/double truncation. It only does wordsize integer/pointer
  operations, at least by default.
* Addition of a simple IR, it is no longer a single pass translation.
* Remove floor, ceil and round float -> int conversions, there is only trunc
  that must have the same result as C casting.
* jit_boadd* and jit_bosub* have a jit_bxadd* and jit_bxsub* counterpart that
  jumps if there is no carry, this may useful when translating code to jit, and
  is also required by the simple redundancy removal when inverting jumps in
  a simple jump threading optimization.
* Labels are pointer objects, that can be created with the jit_label() call,
  or jit_forward() call, one can "patch" forward labels before defining it.
  The label is "defined" with the jit_link(label) call.
* All jump calls no longer receive a label argument, but return a "jump"
  pointer, and it is mandatory to call "jit_patch(jump)" to patch at current
  implicit label, or "jit_patch_at(jump, label)". While this may look like
  it may require more code, it only makes very small examples longer,
  and more complex code cleaner and easier to write.
* There is no jit_leaf() call, only jit_prolog(), but there is a
hidden jit_epilog()
  call that is automatically inserted if another jit_prolog() is found or
  jit_emit() is called, so functions have only one entry and only one
  exit point.
* There is a simple register allocation scheme. One can make a register
  global by calling jit_get_reg(flags) where flags is a specific register
  name and never call jit_unget_reg(reg), but the most common usage
  is to allocate a temporary register. It is advisable to have only one
  global register (using a callee save register) and only have more than
  one temporary based on knowledge of number of registers; not a
  problem to use a lot of temporaries in mips or ppc, but an issue
  in i586.
* jit_prolog() does not receive any arguments, and only non varags C
  callable functions are generated
* jit_prepare() receives a single flag argument, it is mandatory to
  specify if calling a varargs function or not. There is a flaw on it,
  but to avoid needing to specify the point of the "..." in the call,
  it is only supported varargs without fixed float/double arguments,
  otherwise it may fail on some port.

  The above changes are mostly an issue if you already use lightning,
otherwise, 90% of the current lightning.info information is unchanged.

  The approach used is to make it as simple as possible and attempt
to benefit mostly dynamically typed languages conversion to jit.

  If you have any code using lightning, the only non trivial change
should be left to right argument evaluation, other changes are
usually a simple search&replace.

Thanks,
Paulo