public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* How to deal with 48-bit pointers and 32-bit integers
@ 2009-08-12 22:26 Greg McGary
  2009-08-13 14:42 ` Paolo Bonzini
  0 siblings, 1 reply; 2+ messages in thread
From: Greg McGary @ 2009-08-12 22:26 UTC (permalink / raw)
  To: gcc

I'm doing a port for an unusual new machine which is 32-bit RISCy in 
every way, except that it has 48-bit pointers.  Pointers have a 
high-order 16-bit segID and low-order 32-bit seg offset.  Most ALU 
instructions only work on 32 bits, zeroing the upper 16-bit seg ID in 
the result.  A few ALU ops intended for pointers preserve the segID.  
Loads/stores to pointers with segID=0 cause an exception.  The idea is 
to catch bugs where scalars are erroneously used as pointers.  For sake 
of efficiency, GCC can assume that segIDs of pointers are identical for 
pointer arithmetic: there won't be any data objects that span segments, 
and pointer comparisons will always be intra-segment.

I chose to define Pmode as PDImode, and write PDI patterns for pointer 
moves & arithmetic.  POINTER_SIZE is 64 bits, UNITS_PER_WORD is 4.  
FUNCTION_ARG_ADVANCE arranges for both SImode and PDImode values to 
occupy a single register.  I have the port mostly working (passes 90% of 
execution tests), but find myself painted into a corner in some cases.  
What currently vexes me is when GCC wants to promote a PDImode register 
(say r1) to DImode, then needs to truncate down to SImode for some kind 
of ALU op, say pointer subtraction.  The desired quantity is the 
low-order 32 bits of r1, but GCC thinks the promotion to DImode implies 
a pair of 32-bit regs (r1, r2) and since this is a big-endian machine, 
it wants to deliver the low-order bits as the subreg r2.

I now wonder if I can salvage my overall approach, or if I need to do 
things an entirely different way.  I fear I might be in uncharted 
territory since after cursory review, I don't see any existing ports 
where pointers need special handling and are larger than the native int 
size.

Comments?  Advice?

Greg

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: How to deal with 48-bit pointers and 32-bit integers
  2009-08-12 22:26 How to deal with 48-bit pointers and 32-bit integers Greg McGary
@ 2009-08-13 14:42 ` Paolo Bonzini
  0 siblings, 0 replies; 2+ messages in thread
From: Paolo Bonzini @ 2009-08-13 14:42 UTC (permalink / raw)
  To: Greg McGary; +Cc: gcc


> I chose to define Pmode as PDImode, and write PDI patterns for pointer
> moves & arithmetic. POINTER_SIZE is 64 bits, UNITS_PER_WORD is 4.
> FUNCTION_ARG_ADVANCE arranges for both SImode and PDImode values to
> occupy a single register. I have the port mostly working (passes 90% of
> execution tests), but find myself painted into a corner in some cases.
> What currently vexes me is when GCC wants to promote a PDImode register
> (say r1) to DImode, then needs to truncate down to SImode for some kind
> of ALU op, say pointer subtraction. The desired quantity is the
> low-order 32 bits of r1, but GCC thinks the promotion to DImode implies
> a pair of 32-bit regs (r1, r2) and since this is a big-endian machine,
> it wants to deliver the low-order bits as the subreg r2.

Maybe you can define TRULY_NOOP_TRUNCATION to be zero for source PDImode 
and destination SImode, and define a truncatepdisi2 pattern that just 
throws away the segment.  I'm not sure however whether GCC will go 
through DImode anyway.

Alternatively, maybe you can define extendpdidi2 so that it will put the 
segment in r1 and the low-order bits in r2.

Paolo

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-08-13 13:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-12 22:26 How to deal with 48-bit pointers and 32-bit integers Greg McGary
2009-08-13 14:42 ` Paolo Bonzini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).