Daniel Grunblatt wrote:
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
