This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: More PA64 infrastructure



  In message <20000314173635.E454F34D82@nile.gnat.com>you write:
  > On Tue, 14 Mar 2000 08:38:59 -0700, Jeffrey A Law wrote:
  > 
  >   It means we can't have a single compiler that generates PA32 code or PA64
  >   code based on a switch, but we couldn't before this change anyway due to
  >   a number of factors that are unlikely to change.
  > 
  > Could you elaborate a bit on these other factors? It seems unfortunate to
  > me that the 32-bit and 64-bit versions are diverging, and I'd like to
  > understand why that is necessary. Thanks in advance!
Two different object file formats (PA32 uses SOM, PA64 uses ELF).

Two radically different ABIs (arguments growing in opposite directions for
example).

SUBREGs don't work worth a damn when you have registers that are smaller than
word_size (FP registers on the PA have this property).  Combine that with the
need to support FP modes that are twice the word size and you've got an
absolute mess.  It's *far* cleaner to simply not expose the half-word
addressability of the FP registers to the compiler.


The amount of divergence is actually rather small.  They still share everything
in pa.h, pa.c and pa.md.  It's just not possible to build a single compiler
that can generate either PA32 or PA64 code and there is a small amount of
PA32/PA64 specific code in the pa32-regs.h and pa64-regs.h.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]