This is the mail archive of the
mailing list for the GCC project.
Re: how well does gcc support type-specific pointer formats?
- From: Mikael Pettersson <mikpelinux at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Mikael Pettersson <mikpelinux at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 30 Sep 2015 11:59:18 +0200
- Subject: Re: how well does gcc support type-specific pointer formats?
- Authentication-results: sourceware.org; auth=none
- References: <22027 dot 43566 dot 729390 dot 638271 at gargle dot gargle dot HOWL> <CAFiYyc3ntawieo41cV-1iVPexffF8sR0=zcwY7gQeo4fLC=R0Q at mail dot gmail dot com>
Richard Biener writes:
> On Wed, Sep 30, 2015 at 11:23 AM, Mikael Pettersson
> <email@example.com> wrote:
> > Does gcc allow backends to have a say in how pointers are represented
> > (bits beyond the address), what happens in conversions between pointer
> > types, and what happens in conversions between pointers and uintptr_t?
> > The target in question has:
> > - one pointer format and set of load/store instructions for pointers to int/long
> > - another format and set of load/store instructions for pointers to char
> > - pointers to short use a third format in general, but can use the int/long
> > format IF you know which half of the word you're going to access
> > What mechanisms, if any, are present in gcc to deal with this?
> Basically none. The only thing I could imagine you could use is have
> the pointer
> formats be different address-spaces. The target controls how to
> convert pointers
> from/to different address-spaces. I am not aware of specialities for
> or int-to-pointer conversion though - IIRC they simply use
> bit-identical conversions
> (thus subregs if the modes differ).
> But who would design this kind of weird architecture and think he could get
> away with that easily?
It's an old mainframe architecture, not a new design.
A company produced clones up until a few years ago. They also
maintained a private gcc port based initially on gcc-3.2 and
eventually on gcc-4.3, but were unable to rebase on gcc-4.4.
I have access to that port, and am trying to figure out if it
can be reimplemented in some sane say.