Re: [Lightning] Bytecode compiler

[Paulo César Pereira de Andrade]

Em 6 de dezembro de 2010 18:15, Paolo Bonzini <address@hidden> escreveu:
> On 12/06/2010 08:13 PM, Paulo César Pereira de Andrade wrote:

  I finally got something to better figure out requirements and
an initial implementation of a C subset jit compiler, using
lightning at
http://github.com/pcpa/lightning/tree/master/contrib/cjit
[still very initial because code is not actually generated]

>> 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.
>
> This is fine.  Just allocate all space in jit_prepare and replace push with
> mov.

  I started adding requirement for a "jit_putarg_x extension"
requirement in lightning, but I think it may not be the proper
approach, instead, it should build stack frames, and understand
the abi without using jit_arg_x and jit_getarg_x.

  This is because it really needs to know what arguments were
passed in registers so that it can spill them when making a
function call. Also, it should do it to support taking the address
of an argument variable, in which case it would relocate it to
the stack in the parser.
  Also, the jit_putarg_x idea makes it slightly tougher to
generate the intermediate representation, because it would
only know the return value of jit_arg_x when actually generating
jit.

  By understanding the abi, and arguments in registers, it can
also share the same abstraction to implement "register" variables.

  Also, implementing va_list requires figuring out register arguments
at runtime, and alloca may also require some magic.

  Yet another issue is to have freedom to implement struct by value
passing/returning, while at first it is not intended, I may have uses
for calling functions, or fetching return value, with complex double
arguments from jit in my language at some point...

> However, this requires changing the header file name to signify the new ABI.

  I think this may become somewhat optional for the "cjit sample",
and maybe not worth it for now, besides would make mips and
x86_64 argument handling slightly easier, it could require lightning
users to rewrite/review a good amount of code.

>> 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.
>
> This is already supported, but you have to use addc/addx manually.
> Multi-word values simply do not belong in a low-level IR such as lightning.
>
>> 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",
>
> This can be isolated in your IR, it doesn't need to be known to lightning.

  The initial implementation uses a very dumb register allocator, but indeed,
it should be better to have it done in the code feeding the IR, not the IR
itself, that is basically "unrolled" data to feed lightning.
  The register allocator should be changed soon understand more than
2 register classes (int/pointer and float) to also understand a "prefer callee
saved bit", and probably an accessible as 8 bit and/or direct target to
jit_ltr_x like functions bit. Maybe also some information to know if it has
only two register opcodes and such (currently the code generation uses
the pattern that unary operations are better done if using same register as
source and destination, and binary operations with left argument as
destination).

>> jit_push/jit_pop would not be easily possible,
>> I already dislike it :-)
>
> They are deprecated anyway.
>
> Paolo

Paulo