Re: [Lightning] Bytecode compiler

[Paulo César Pereira de Andrade]

2010/12/3 Paolo Bonzini <address@hidden>:
> On Fri, Dec 3, 2010 at 10:36, Dok Sander <address@hidden> wrote:
>> Hi,
>>
>>  I haven't have any luck finding out about a compiler that generated GNU 
>> Lightning bytecode. I find this weird that there isn't a GCC version that 
>> would do this((like gcc-llvm) So, i'd like to know if such an project exists 
>> at all or is under development somewhere?
>
> GNU Lightning is more suited to creating JIT compilers via templates.
> So, it's a bit like programming in assembly language.
>
> Paulo Pereira has an interpreter for GNU lightning opcodes that (IIUC)
> compiles and runs the opcodes passed as input.

  Going a bit off topic in some points, but continuing some ideas
I commented some weeks ago...

  In my language, I started implementation of a generic intermediate
representation to be processed before actually emitting code, but
currently it is only used to allow building lists in parallel; one for
integers, one for floats, and another for "unknown" type (also used
on integer overflow) that fallbacks to "slow" type check and dispatch.

  The major problem of an intermediate representation, is that to
be effective, it would require changes in lightning itself. It could
even have a mode where gcc could generate lightning input, but
in the current lightning state, it actually would be better to have
a "lightning port to C" :-), that is, a port to a bytecode format, using
gcc's computed gotos and a fallback to switch/case [1].

  After writing the "pseudo assembler", for test cases, I have been
considering to write a simple C dialect on top of lightning, to have
it as the test tool for the intermediate interface, but, it could even
become a generic tool.

  This is mostly about my interest on lightning, but, as long as
it does not add too much overhead, or cause lightning to miss
its point (a simple/small and fast jit generator), some changes
I would want to add to a generic intermediate representation
include:
o Left to right argument evaluation; when passing arguments
  in registers, right to left just make things harder than they
  should be and also unnatural, I managed to get along for
  x86_64 varargs, but mips n32 abi is really designed to build
  stack frames left to right. I believe the right to left approach
  is a remaining of i386 only/initial code, or is working with
  register windows easier right to left also? Sorry, no experience
  with sparc...
  This could also cause some issues with code that jumps from
  code from one jit_prolog to another, and is the only reason I
  did make default in my fork the "push_pop" option.
o "l" "ell" modifier is 64 bits. "ll" probably would only add
  confusion, but the idea would be to support 64 bit values
  on 32 bit.
  Not trivial to fully implement as it would require receiving and
  returning these values in jit functions, as well as a kind of
  register set abstraction; also usable to export packed/vector
  registers like x86 mmx/xmm/ymm, mips packed single float,
  or other sets in other architecture.
o The intermediate representation also would have the advantage
  of being able to do better register allocation, but would require
  some kind of "virtual registers", where the user could create
  treat some identifier as a register, and the generator would
  do register spilling on some stack area; the user should also
  be able to do it if not using more register than available hardware
  ones...

> Paolo

[1] Actually, the major change to the "api" could be the requirement
of another approach to call a jit function. Maybe could get along
with something like:
  jit_call(jit_insn *, ...);
and use varargs to fetch the arguments. Calls to non "C port"
jit functions would require libffi (gcc or standalone - bsd), or
ffcall (clisp - gpl). jit_allocai should require alloca being
available. jit_push/jit_pop would not be easily possible,
I already dislike it :-)

--
Paulo