I wish to understand the JIT machine code generator

9 views
Skip to first unread message

ro...@adampreble.com

unread,
Apr 13, 2005, 12:33:51 AM4/13/05
to perl6-i...@perl.org
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?

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

unread,
Apr 13, 2005, 3:21:59 AM4/13/05
to ro...@adampreble.com, perl6-i...@perl.org
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.
> 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

unread,
Apr 14, 2005, 1:50:06 AM4/14/05
to perl6-i...@perl.org
Quoting Leopold Toetsch <l...@toetsch.at>:

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

unread,
Apr 14, 2005, 5:39:26 AM4/14/05
to ro...@adampreble.com, perl6-i...@perl.org
ro...@adampreble.com <ro...@adampreble.com> wrote:

> 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

unread,
Apr 14, 2005, 7:36:23 AM4/14/05
to ro...@adampreble.com, Perl6 Internals List
On Thu, 2005-04-14 at 01:50 -0400, ro...@adampreble.com wrote:

> > 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.

Reply all
Reply to author
Forward
0 new messages