[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lightning] Bytecode compiler
From: |
Paolo Bonzini |
Subject: |
Re: [Lightning] Bytecode compiler |
Date: |
Mon, 06 Dec 2010 21:15:02 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6 |
On 12/06/2010 08:13 PM, Paulo César Pereira de Andrade wrote:
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.
However, this requires changing the header file name to signify the new ABI.
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.
jit_push/jit_pop would not be easily possible,
I already dislike it :-)
They are deprecated anyway.
Paolo