On Thu, 2005-04-14 at 01:50 -0400, [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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.
