Re: does gcc support multiple sizes, or not?

[Mark Mitchell <mark at codesourcery dot com>]

DJ Delorie wrote:
>> Well, I think it's in direct conflict with the C++ standard.  If "X" is
>> a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit
>> pointer type, then:
>>
>>   (X*)(Y*)x
>>
>> is supposed to get you back the value of "x", but I don't see how that
>> can work, in general.

I made an error in the code above; I should have said "(X)(Y)x" since I
had already defined "X" and "Y" to be pointer types.

> Where in the standard does it say that?

[expr.reinterpret.cast]

  A pointer to an object can be explicitly converted to a pointer to  an
  object of different type.13) Except that converting an rvalue of  type
  "pointer  to  T1"  to  the  type  "pointer to T2" (where T1 and T2 are
  object types and  where  the  alignment  requirements  of  T2  are  no
  stricter  than  those  of T1) and back to its original type yields the
  original pointer value, the result of such  a  pointer  conversion  is
  unspecified.

The "except that" sentence implies the statement above, assuming that
the pointed-to type does not have stricter alignment.  So, if casting a
32-bit pointer to int to a 16-bit pointer to char and back does not
always yield the same value, then something has to give.

Fundamentally, pointer types in C++ are compound types determined solely
by the pointed-to-type; what you're doing (by adding attributes to the
pointer) is adding a new operator for forming compound types.  That's a
language extension, so it needs to be specified.  It's not enough just
to tweak the back end to allow the mode attribute.

>> You only need two classes of pointers if you expect people to use
>> the second class in non-trivial expressions, i.e., dereference them,
>> perform pointer arithmetic on them, etc.
> 
> Like the m16c, which lets you put additional less-frequently used data
> in function memory?  Perhaps, a table of strings, or some CRC lookups?

If you really need two classes of pointers, then, sure, you need them.
All I did was ask whether or not you really need them and offer a
possible solution if you *don't* need them.

I am aware of "near" and "far" pointers in Borland (and other)
compilers.  That's good news; you may have an example to help work
through the issues.  That doesn't mean that there are no issues.

You seem to be trying to convince me that this is a simple thing and
that we should just do it and let the chips fall where they may.  You
might be right -- but since almost every other such change has lead to
trouble, I'm not inclined to take chances.  Please do the work up front
to specify how this interacts with all aspects of the language.  That's
user documentation we need anyhow.

I do think this sounds like a useful feature.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713