[Lightning] Lightning extensions

[Paulo César Pereira de Andrade]

  Hi,

  I think the work on x86_64, other than some cleanup is probably
almost done, in the sense that it should not modify interfaces, and
only correct bugs. My latest test
http://code.google.com/p/exl/source/browse/trunk/check/lightning/clobber.tst
did not find any problems (first time a full test does not find any :-),
but I may still extend it to work slightly different, based on cpp
defines passed on the command line, so that it would only use 5
integer registers the entire run, but every check* macro, ensure
the "unused" register was not clobbered.

  About "extensions", it is extra work, that, while expecting
to not change, break or remove features, could require changes
on current code using lightning:

o Use of inline/standard functions is really desirable, to have
  better logic control. Major issue is that it could break logic
  that depends on macro expansion, e.g. instead of doing
  something like "#define _jitl something", would need
  something more like jit_set_context(_jitl)
  It would also require changing some macros that receive
  a macro name as argument, e.g. jit_replace* and others.

o Choose code generation based on runtime cpu features.
  Most simple example is the required rework to use SSE*
  on x86, and desirable access to ix87 on x86_64. But also,
  SSE registers can be used for integer arithmetic, and
  int128 is very desirable for the target users of lightning,
  i.e. dynamically typed languages, or languages that
  want to know exactly when an overflow happened.

o Some kind of peephole optimization. This is kind tough,
  and may become quite complex. Again, talking about
  x86*, it could convert some "ldr_x r0 r1; alur_x r0 r2 r0"
  into something more like "alum_x r0 r2 r1", where the
  "m" modifier stands for (m)emory. To have a simple
  peephole optimization it would require a different
  approach to handle labels and patches, and that could
  become very memory hungry, at it would most likely
  need to store operations in lists, up to jit_flush_code(),
  so, maybe the idea should be discarded by default...

  Either way, I will do some experiments, while working
on generating more native code and less "glue code" in
my language.

Paulo