Re: [Lightning] Adding support for a multi pass intermediate representation

[Paulo César Pereira de Andrade]

Em 9 de novembro de 2010 05:23, Paolo Bonzini <address@hidden> escreveu:
> On 11/09/2010 01:44 AM, Paulo César Pereira de Andrade wrote:
>>
>> >  Ok, so what I had missed is that the design is specific to your VM.:)
>>
>>   I think I did not make myself clear:-)  I posted to the list because
>> most of the concept is generic, and I plan to implement a proof of
>> concept of it shortly. The part specific of my VM is that it needs to
>> "hack" the generic one (or have an interface) to have 3 lists that
>> are merged from time to time.
>
> Ok, got it.  But I think that it's better if your VM first does "type
> inferencing" using a standard dataflow algorithm on its own IR, and then
> proceeds normally with the generic interface.

  Yes. Actually doing it, at least type and value range inference was one
of my next steps some months ago, but I stopped to work on lightning :-)
But I think it was and is still being productive, spotlights should be sse
on i386 and mips port (it pass all tests in contrib/check and all tests in
my vm, but so far tested only on mipsel 32 bits and using the o32 abi,
most bits in place for 64 bit, just need a distro image with gcc/gdb/binutils;
I think there may be a debian mips64 now), and I also hope to possibly
work on an arm port soon.

  Most of the current work is experiments tough, but also good results;
actually, in the rework of the initial "scratch" idea, now dynamically
typed operations are only slightly slower than typed ones, and with
more information and better code generation, it actually should be
possible to generate code comparable to optimized C code speed
(the language uses a C like syntax anyway, just that it is dynamically
typed with optional type declaration, garbage collected, etc :-)

  But I probably will follow your advice, as the current code generation
is getting hardly maintainable and not very clear code. Also, it does
not make much sense looking at the disassemble and seeing all those
float opcodes on code handling only integers (that is, it should infer
that a loop counter variable will never be a float neither overflow)...

> Paolo

Thanks,
Paulo