This is the mail archive of the 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: does gcc support multiple sizes, or not?

> I'm very suspicious of allowing users to specify this via attributes.

Me too, but that's what extensions are all about.  You never know what
the user is going to need to do.

The M16C is an example - it has a 16 bit pointer, but has a few
special opcodes for using a 32 bit pointer to access additional ROM
data.  Plus, functions exist in a 24 bit address space.

> Having pointers-to-objects or pointers-to-functions with different sizes
> (within one of those classes) seems problematic, but perhaps you can say
> more about how you expect this to work in the presence of conversions
> and such.

I don't know about conversions, but I can easily imagine cases where
the program's address space isn't as big as the chip's address space.
Consider a 32-bit program on a 64-bit CPU, which needs to access
memory mapped devices.  Or an API converter that lets 32 bit programs
run in a 64 bit OS.  They'd need to compute pointers as integers of
the right size, then cast them.

> I expected that what you were asking was whether the back end could
> reasonably say that function pointers had size four, say, while data
> pointers had size two.  I think that's reasonable,

That is totally unsupported by GCC.  I've ranted about that before,
because the m16c has a 16 bit data pointer and a 24 bit function

> but I don't find it nearly so reasonable to say that some "int *"
> pointers have size four while others have size two.  But, maybe I
> just need appropriate motivation.

Well, it seems to work just fine in C.  Example: In m16c, you can
declare an SImode pointer type, which is initialized to point to a
function.  The assembler does the right thing, letting you initialize
a reset vector (32 bit pointers) without having to set up the RAM
thunks to support 16 bit function pointers.

> Also, there is a nasty class of bugs in G++ stemming from the GCC
> attribute extensions because there are no well-defined rules about how
> to tell if two types with different attributes are the same or
> different, and if they are different what conversions (if any) can be
> used to convert back and forth.

We have target hooks for function attributes, no reason to avoid
target hooks for data attributes.

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