[RFC] unified core.jit
Leopold Toetsch
similar, e.g. checking for MAPped registers, but differ depending on
the processor architecure: basically we have 3 register machines
(alpha, arm, ppc, sparc) and a 2 register machine (i386).
My proposal is to write a universal core.jit, which provides the basic
functionality.
e.g.
Parrot_add_i_i_i {
if (MAP[1] && MAP[2] && MAP[3]) {
#ifdef jit_emit_add_rrr_i /* 3 reg machine */
jit_emit_add_rrr_i(MAP(2), MAP(3), MAP(1));
#else
jit_emit_mov_rr_i(MAP(2), MAP(1));
jit_emit_add_rr_i(MAP(3), MAP(1));
#endif
}
...
The implementation of these jit_emit_ops would stay in jit_emit.h.
Proposed naming of ops:
jit_emit_<op>_<rmi>_<in>(...)
<op> operations mov, add, sub, mul, ...
<rmi> register, memory, immediate, for all parameters
(source, dest) or (source, source, dest)
<in> integer (or pointer...) or number
jit_emit_mov_rm_n(<reg>, <mem>)
(store processor reg to parrot num_reg at mem)
jit_emit_mov_mr_i(<mem>, <reg>)
(load processor reg from parrot int_reg at mem)
The <reg>s would be taken from a list of processor regs, either the
MAPed ones, or 1 or 2 scratch registers, depending on architecture.
jit_emit_jmp_p(<cond>, offset)
jit_emit_call_p(offset)
Jump to or call parrot funcs at offset.
<cond> : cond_always, cond_lt,le,gt,ge,eq,ne
jit_emit_push_<rm>(.., &SP_diff)
jit_emit_call_c(addr)
jit_emit_call_vtable(mem_of_pmc_reg, int n)
jit_emit_add_SP(SP_diff)
jit_emit_ret
Push (or whatever) params on stack, preparing for a native call,
correct SP after return.
With these ops, all the current functionality could be in one file,
all the register mapping would be centralized.
If something doesn't fit, it could be undefined for this architecture,
the implementation would then be in jit_emit.h.
Comments welcome
leo
Daniel Grunblatt
The problem is when you want to implement an opcode like div, which is easy in
ppc but not in arm.... ideas?
I was sort of going in that direction, mips/core.jit is almost like
ppc/core.jit (If everything is on schedule I'll find some time to finish it
on december).
Daniel Grunblatt.
Leopold Toetsch
> I would do a cisc.jit and a risc.jit to avoid the #ifdef forest.
Good idea.
> The problem is when you want to implement an opcode like div, which is easy in
> ppc but not in arm.... ideas?
I don't know arm, but this belongs to jit_emit.h, how it's done there is
a different issue.
> I was sort of going in that direction, mips/core.jit is almost like
> ppc/core.jit (If everything is on schedule I'll find some time to finish it
> on december).
Ah fine.
But can we have a united syntax for {c,r}isc.jit. The problem currently
is, that moves or other ops are sometimes written as op(src, dest),
sometimes exactly the other way round.
I really want this have sorted out. I'm currently writing tests
(jit/i386 is failing a lot of them, due to wrong move directions: e.g.
add_i_i_i, sub_i_i_i)
>>Proposed naming of ops:
>>
>> jit_emit_<op>_<rmi>_<in>(...)
>>
>> <op> operations mov, add, sub, mul, ...
>> <rmi> register, memory, immediate, for all parameters
>> (source, dest) or (source, source, dest)
We could do it like parrot (dest, src, src) too, but I want really a
unique naming convention.
leo
Daniel Grunblatt
> Daniel Grunblatt wrote:
>
> > The problem is when you want to implement an opcode like div, which is
> > easy in ppc but not in arm.... ideas?
>
> I don't know arm, but this belongs to jit_emit.h, how it's done there is
> a different issue.
>
what if we just don't want to implement that opcode in this specific
architecture?
> But can we have a united syntax for {c,r}isc.jit. The problem currently
> is, that moves or other ops are sometimes written as op(src, dest),
> sometimes exactly the other way round.
>
> I really want this have sorted out. I'm currently writing tests
> (jit/i386 is failing a lot of them, due to wrong move directions: e.g.
> add_i_i_i, sub_i_i_i)
>
> >>Proposed naming of ops:
> >>
> >> jit_emit_<op>_<rmi>_<in>(...)
> >>
> >> <op> operations mov, add, sub, mul, ...
> >> <rmi> register, memory, immediate, for all parameters
> >> (source, dest) or (source, source, dest)
<rmid> register, memory, immediate, displacement
>
> We could do it like parrot (dest, src, src) too, but I want really a
> unique naming convention.
>
> leo
Cool, let's do it like parrot.
I just committed a renaming for the ppc.
I believe that Parrot_end will have to call jit_emit_end() that will reside in
jit_emit.h and will be just like Parrot_end is now since every calling
convention is different.
Daniel Grunblatt.
Nicholas Clark
> On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
> > We could do it like parrot (dest, src, src) too, but I want really a
> > unique naming convention.
> >
> > leo
>
> Cool, let's do it like parrot.
Good call.
I think it's the least confusing way round. At worst parrot assembler and the
JIT share the same ordering, and the platform's native assembler is the other
way. At best all three are the same way round.
Nicholas Clark
--
Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Leopold Toetsch
> On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
>
>>Daniel Grunblatt wrote:
> what if we just don't want to implement that opcode in this specific
> architecture?
Prefered: provide a native function doing the e.g. "div" and call this
function from within the emitted code.
Or praeprocessor magic, redifining the Parrot_jit_ops to Parrot_jit_native
> Cool, let's do it like parrot.
Yep, same parameter ordering is a good thing(tm).
> I just committed a renaming for the ppc.
and others in the meantime - good.
Are these _load & _store different or will they just become _mov. (The
displacement-suffix is IMHO not needed on the surface.
I'm thinking of a structure like this:
generic.jit ... 3 operand machine with op_r_r_r ... op_m_m_m
risc.jit ... 3 register machine, 2 scratch for memory ops
cisc.jit ... 2 register machine, 1 scratch
$arch.jit ... overriding if necessary and when present
generic.jit implements the register MAPping and could probably be
autogenerated from core.ops.
risc.jit provides macros for preparing the scratch registers for the
memory operands, cisc.jit similar.
$arch.jit could implement anomalies like i386 shift ops.
> I believe that Parrot_end will have to call jit_emit_end() that will reside in
> jit_emit.h and will be just like Parrot_end is now since every calling
> convention is different.
Yes.
> Daniel Grunblatt.
leo
Daniel Grunblatt
> Or praeprocessor magic, redifining the Parrot_jit_ops to Parrot_jit_native
OK.
> > I just committed a renaming for the ppc.
>
> and others in the meantime - good.
> Are these _load & _store different or will they just become _mov. (The
> displacement-suffix is IMHO not needed on the surface.
True true.... I'll fix that now.
>
> I'm thinking of a structure like this:
> generic.jit ... 3 operand machine with op_r_r_r ... op_m_m_m
> risc.jit ... 3 register machine, 2 scratch for memory ops
> cisc.jit ... 2 register machine, 1 scratch
> $arch.jit ... overriding if necessary and when present
>
> generic.jit implements the register MAPping and could probably be
> autogenerated from core.ops.
> risc.jit provides macros for preparing the scratch registers for the
> memory operands, cisc.jit similar.
> $arch.jit could implement anomalies like i386 shift ops.
>
I don't really know if we should spent too much time on this instead of
creating an intermediate language to write opcodes on it.
Daniel Grunblatt.