PDP-10 backend for gcc

[Michael Meissner]

On Fri, Sep 01, 2000 at 11:16:06AM +0200, lars brinkhoff wrote:
> Jeffrey A Law <law@cygnus.com> writes:
> > > Oh.  But the back end MUST know whether it's operating on pointers or
> > > integers.  Byte pointer subtraction on a PDP-10 is much different from
> > > integer subtraction.  Basically, PDP-10 byte pointers are not are not
> > > integers, at least not with respect to how arithmetic are performed on
> > > them.
> > You've got a significant problem then.  You're most likely going to have
> > to use something like PSImode or PDImode or something new to represent
> > your pointers.
> > 
> > Fundamentally GCC assumes that arithmetic on pointer types works just
> > like arithmetic on integer types.
> 
> There are two kinds of pointers:
> 
>   Word pointers.  These are 30-bit values in 36-bit words, and are
>   used to point to anything at least one word in size.  Integer
>   arithmetic works.  I think PSImode will work here.
> 
>   Byte[*] pointers.  These are 36-bit values in 36-bit words.  The
>   lower 30 bits is a word pointer, and the upper 6 bits is a code
>   to locate the byte (i.e. char or short) within the word pointed
>   to.  Since normal ints are 36-bits, SImode can't be used for byte
>   pointers.  Maybe a new mode will have to be invented?
> 
> [*] On a PDP-10 a "byte" is defined as any contigous bit field in a
> 36-bit word.

Sorry, I was not replying to external mail for a few days.  As the others have
said, GCC internally believes that all pointers are byte pointers, and it can
just add 1 to a pointer to increment to the next byte.  That means without
reworking the code, you would not be able to use any other format, such as
using the upper bits for the byte offset, etc.

If I remember my computer architecture classes, the classical way to represent
characters on a -10 was to have 5 7-bit fields with a bit left over.  This
violates ISO C, which mandates that all types be a whole number of bytes (so
that memcpy works), and that a byte be at least 8 bits.  This would mean you
would have to use either 36-bit bytes, or 9-bit bytes.  The path of least
reistance is to have 36-bit 'bytes'.  This is the path chosen by other word
oriented machines, such as the C4x.

It would be useful to have GCC be able to deal with different sized pointers
and/or different encodings for the pointers.  I have run into this on some
machines, such as the Mitsubshi D10V (function pointers are 16-bit word
pointers, while data pointers are 16-bit byte pointers), but I suspect you will
have to get buy-in from the people that work on the front ends (ie, the TREE
interface), since that is where a lot of the work will need to be done.  Given
this byte pointer-ness has been in the compiler since its inception, I suspect
you will find undocumented assumptions rife throughout the compiler.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482