Ben Lippmeier wrote:
Simon Marlow wrote:
Sorry about that - I hadn't noticed that the sparc NCG had these
hard-coded.
No worries.
Would it be possible to do it like the other backends where all the
information is taken from MachRegs.h?
Sure.
I had originally given the sparc NCG its own local register definitions
to help move towards being a cross-compiler. The trouble is that names
like REG_R1 have no architecture specific meaning. There's nothing
distinguishing the x86 REG_R1 from the sparc REG_R1, and only one of
them is defined for any particular build.
It'd probably be better to change MachRegs.h to define things like:
X86_REG_R1 esi
SPARC_REG_R1 l1
We'd use these internally to the compiler, but then include a different
header when producing code via-c:
#ifdef sparc_TARGET_ARCH
#define REG_R1 SPARC_REG_R1
...
Either that or change the via-c path to use the arch specific names.
In the interim I can just change MachRegs.h to use SPARC_REG_R1 and
friends and leave the defs for the other arches alone, or something.
I agree it would be better to make MachRegs.h define register settings for
all architectures. However, I don't think you need to change it just for
Sparc: just #include "MachRegs.h", and as long as sparc_TARGET_ARCH is
defined you'll get the right settings. That's the way it seems to be done
for the other arch's at the moment.
In fact it looks like the e.g. the x86 NCG will generate bogus code when
compiled with sparc_TARGET_ARCH because the register settings will be
wrong. Obivously we should refactor MachRegs.h to fix this, but it's not
breaking anything that we care about right now. So I guess I'm just saying
that we could wait and fix them all at the same time.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
