I wish to understand the JIT machine code generator
ro...@adampreble.com
would be to create an AMD64 code generator. Unfortunately, the code is
uncommented, and I haven't yet found any documentation to explain how it works
on Parrot. So far I've determined there's relevant stuff in jit/i386. I don't
understand the .jit extension on core.jit. Is that not actually heavily
templated C code?
I'm curious if there's other sources to study. Preferably, I'd like to get some
advice on how to study this code generator so I can at least improve it. I'd
prefer to become knowledgeable enough to add an AMD64 generator sometime.
However, I'll gladly advise only if somebody has already started it.
Leopold Toetsch
> I have been trying to examine the i386 code generator to see how
> feasible it would be to create an AMD64 code generator.
> Unfortunately, the code is uncommented, and I haven't yet found any
> documentation to explain how it works on Parrot. So far I've
> determined there's relevant stuff in jit/i386. I don't understand the
> .jit extension on core.jit. Is that not actually heavily templated C
> code?
jit/*/jit_emit.h defines basically a bunch of macros that emit opcodes.
There are additionally some interface functions like
Parrot_jit_begin(), Parrot_jit_normal_op and the register move functions
called from src/jit.c to copy registers from Parrot to CPU and back.
i386 has additional code to emit NCI stubs and direct vtable calls,
which all is optional. docs/jit.pod has some more details on the
interface functions.
The format of jit/*/core.jit is also covered by doc/jit.pod. It defines
JITted opcode functions which, when called by the code generator in
src/jit.c, emit code for the function. It makes use of templates to
generate the final code in src/jit_cpu.c and src/exec_cpu.c.
Please have a look at these generated files and the docs. If there are
some more questions, please just ask.
leo
ro...@adampreble.com
Thank you. The POD is a little thick, and I'll be printing it out so I can
follow along. I'm going to copy the i386 path to an a64 path and have at it.
I'm hoping it won't be much of a stretch to get 64-bit code generated --
although REASONABLE 64-bit code is another problem. But first I want
to ask if
anybody else is doing this already. I don't know what I'm getting
myself into,
other than at least modifying ~5,000 lines of code.
Leopold Toetsch
> Thank you. The POD is a little thick, and I'll be printing it out so I can
> follow along. I'm going to copy the i386 path to an a64 path and have at it.
> I'm hoping it won't be much of a stretch to get 64-bit code generated --
> although REASONABLE 64-bit code is another problem. But first I want
> to ask if
> anybody else is doing this already.
Yep.
> ... I don't know what I'm getting
> myself into,
> other than at least modifying ~5,000 lines of code.
The biggest problem with jit/i386/jit_emit.h is that there are two
layers above one another: old code C<emit_*> and the newer and more
regular C<jit_emit_*> as described in the naming conventions for JIT
code. And to complicate matters and bewilder a casual hacker operand
directions are reversed between the two layers.
It's probably best to start over with a cleaner implementation that
additionally has a notion of the REXX prefix for x86-64. I don't know
anything about license issues, but:
$SRC/mono-1.x.y/mono/arch/amd64/amd64-codegen.h
might be a better start.
leo
Aaron Sherman
> > ro...@adampreble.com <ro...@adampreble.com> wrote:
> >
> >> I have been trying to examine the i386 code generator to see how
> >> feasible it would be to create an AMD64 code generator.
[...]
> I'm going to copy the i386 path to an a64 path and have at it.
> I'm hoping it won't be much of a stretch to get 64-bit code generated --
> although REASONABLE 64-bit code is another problem. But first I want
> to ask if anybody else is doing this already.
Just one thought on stylistic conventions. GCC uses the following naming
conventions for AMD processors, and I imagine that they have had to do
this because they have discovered over the years that it makes sense:
k6 AMD K6 CPU with MMX instruction set support.
k6-2, k6-3
Improved versions of AMD K6 CPU with MMX and 3dNOW! instruc-
tion set support.
athlon, athlon-tbird
AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and SSE
prefetch instructions support.
athlon-4, athlon-xp, athlon-mp
Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and
full SSE instruction set support.
k8, opteron, athlon64, athlon-fx
AMD K8 core based CPUs with x86-64 instruction set support.
(This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and
64-bit instruction set extensions.)
Since Parrot's JIT will need to think about the CPU in ways that are
roughly analogous to the way GCC's RTL-to-machine generator thinks about
it, perhaps you'll want to start off with similar categorization.
Also, looking at the m-* files in the GCC source tree could easily give
you some pointers on what it is that you might want to be thinking about
for optimal code-gen under Parrot.
It would be awesome if someone figured out a way to translate GCC's m-*
templates into some sort of starting point for Parrot JIT definitions,
but that might be too science-fictiony to make sense, as GCC is defining
translations for RTL sequences and Parrot is defining translations for
PBC ops, which are very different.