Re: making sizeof(void*) different from sizeof(void(*)())

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Sat, Apr 28, 2012 at 02:32:18PM -0500, Peter Bigot wrote:
> The MSP430's split address space and ISA make it expensive to place
> data above the 64 kB boundary, but cheap to place code there.  So I'm
> looking for a way to use HImode for data pointers, but PSImode for
> function pointers.  If gcc supports this, it's not obvious how.
> 
> I get partway there with FUNCTION_MODE and some hacks for the case
> where the called object is a symbol, but not when it's a
> pointer-to-function data object.  As an example, bootstrapping fails
> in libgcc/unwind-dw2-fde.c because the fde_compare pointer-to-function
> object is stored in a HImode register instead of a PSImode register.
> 
> The only candidate solution I've seen (and haven't yet tried) is to
> somehow assign all functions to be in a special named address space
> and use TARGET_ADDR_SPACE_POINTER_MODE to override the normal use of
> ptr_mode in build_pointer_type.
> 
> I haven't been able to identify an existing back-end that has such a
> case, though I'd swear I've seen memory models like this for some
> other processor in the past.

In the original 1989 ANSI C standard (which became the 1990 ISO C standard)
function pointers could be a different size than void * pointers.  In that
standard, void * and char * had to have the same underlying size and
representation.  I don't recall if C99 changed this in any way.

The D10V port sort of cheated in that it had 16-bit pointers that were byte
pointers for data, and 16-bit pointers that were word pointers for functions,
and it caused a number of issues, back when I did the D10V many years ago.
However, since the D10V has been removed quite some time ago, it is no longer
relevant.

Another way to go is what we do in 64-bit powerpc -- function pointers are
actually pointers to a 3 word descriptor, that contains the real function
address, the value to load into the GOT pointer, and the value to load into the
register holding the static chain.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com	fax +1 (978) 399-6899