Re: Abstracting pointer arithmetic

[Michael Meissner <meissner at cygnus dot com>]

On Tue, Jan 30, 2001 at 08:24:20AM +0100, Lars Brinkhoff wrote:
> Michael Meissner <meissner@cygnus.com> writes:
> > >   The machine description should define insns for pointer arithmetic.
> > >   They should be named "addsip3", "subsip3", "subpsi3", "tstp", and
> > >   "cmpp", or something like that.
> > While this is arguably a step in the right direction, it still
> > assumes that there is only size for pointers, and that all pointers
> > are the same size and format.  If we really want GCC to deal with
> > the difficult machines, such as machines with word pointers, you
> > have to allow for different sizes (which means different modes),
> > etc.
> 
> True.
> 
> > Consider a 'typical' word pointer machine.  If the pointer is a
> > pointer to an integer aligned type (and aligning all struct/unions
> > to meet the requirement that all struct/union pointers have the same
> > size/format), you might want Pmode to translate into PSImode, but if
> > the pointer is a pointer to a short or byte, it gets translated into
> > PDImode.  You really need a macro that takes the pointer tree type
> > and gives the appropriate type.
> 
> So something like
>         #define Pmode_FROM_TYPE(TYPE) ...
> should go into the target description?  What if the tree type isn't
> avilable any more when GCC wants to call that macro?  For example,
> there are a lot of calls to gen_rtx_FOO (Pmode, ...).  Should there be
>         #define Pmode_FROM_RTX(X) ...
> or
>         #define Pmode_FROM_MODE(MODE) ...
> too?

Pmode as it exists in GCC is completely broken if you are going to deal with
different pointer sizes.

> Are there any machines with different pointer formats depending on
> the contents of the data pointed to?  Like different pointers for
> int * and float *?  Or diferent pointer formats for functions and
> variables?

Yes there are and have been such machines.  For example, the Data General
MV/Eclipse computers (mostly RIP) that I wrote a C compiler front end before
coming to GCC had 4 different types of pointers at the hardware level.  There
were pointers to bytes, which had the segment/ring number in the upper 3 bits,
and the offset in the remaining 29 bits; pointers to 16-bit words, which was
the byte pointer shifted right one bit, and the top bit being used as an
indirection bit; pointers to bits which involved a word pointer plus a bit
offset pointer; and a reduced bit pointer that could only reach a part of the
address space.

As a more practical example, one of the machines GCC has been ported to (but
that hasn't been donated to the FSF at the current time due to various factors)
is the Mitsubshi D10V, which is a 2-pack VLIW machine.  Instruction words
consist of either 2 short instructions that are either done serially or in
parallel, or one long instruction.  The machine is a 16-bit machine, and data
pointers are the normal byte pointers.  The instruction pointers are pointers
to an 18-bit instruction space, with the bottom 2 bits always 0, since
instructions take 32 bits.  There are OS mapping registers that control where
in the 32-bit address space the text and data pointers point to.  One of the
persistant problems with targeting GCC to that machine was the insistance on
transforming pointers to integers at an early stage without type information.
I think there may be some other 16-bit chips that have a similar problem.

Certainly in the days of the 8086 there were memory models where the size of
the function pointers was different than the size of the data pointers.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
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