This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sun, Apr 29, 2012 at 7:51 AM, Georg-Johann Lay <avr@gjlay.de> wrote:
> Peter Bigot a écrit:
>
>> 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.
>
>
> I don't think it's a good solution to use different pointer sizes.
> You will run into all sorts of trouble -- both in the application and
> in GCC.

Seems to be true in gcc at least.  In C, I thought void* and void(*)()
were so fundamentally incompatible that it was perfectly legitimate to
have them be different sizes.  (It was memory models on the DEC Alpha
a decode or more ago that I recall as having that feature.)

Are there really no gcc back-ends that take advantage of this?

> Besides that, named address spaces are for data, not for functions.
> And they are supported for C only, not for C++, Objective-C, etc.

In that case, I'll ignore them and move to using variable and function
attributes.  It just seemed nice that it was possible to adapt the
pointer mode based on the address space; it'd be nicer if it could be
modified based on the full type, though.  TARGET_TYPE_POINTER_MODE
maybe.

>
>> 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.
>>
>> Could somebody suggest a workable solution for 4.7.x?
>
>
> AVR has similar problems to solve, see
> http://gcc.gnu.org/ml/gcc/2012-01/msg00365.html
>
> On AVR, the problem only arises for functions outside 128 KiB
> because instructions are always 2-byte aligned. Consequently,
> function pointers hold word-addresses.
>
> An easy solution would be to align function entry points and
> labels of computed and non-local goto to 2^n bytes. That way
> 16-bit pointers can target addresses in 2^n * 64 KiB.
>
> Other approach is linker stubs as mantioned in the link above.

MSP430 has direct support for calling with a 20-bit pointer, so going
through an indirection step is suboptimal.  Also, a memory model
supporting 16-bit data pointers and 20-bit code pointers is standard
for commercial compilers for MSP430, so I'm a bit surprised at the
possibility that gcc wouldn't support it.  I assumed I just wasn't
finding the right tickle-points.

Peter


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]