Re: does gcc support multiple sizes, or not?
> So... who is right? Are we supposed to support multiple pointer sizes > in the same compilation unit, or not? Who's "we"? The middle-end and relevant back-ends support it, but clearly not all the front ends. C and Ada does but your experiment seems to show that C++ does not.
Re: does gcc support multiple sizes, or not?
However, in s390.c, we have:
static bool
s390_valid_pointer_mode (enum machine_mode mode)
{
return (mode == SImode || (TARGET_64BIT && mode == DImode));
}
Note that more than one mode is supported simultaneously. Thus, it's
legal for the application to specify SI or DI mode for pointer (via
__attribute__((mode))), but cc1plus then aborts.
So... who is right? Are we supposed to support multiple pointer sizes
in the same compilation unit, or not?
Hmm... this worked when I put this in for s390 at one point - for
exactly the reason that you have with the attribute.
-eric
Re: does gcc support multiple sizes, or not?
> Who's "we"? "We" means "gcc". > The middle-end and relevant back-ends support it, but clearly not > all the front ends. C and Ada does but your experiment seems to > show that C++ does not. Does this mean that there's a bug in the C++ front end?
Re: does gcc support multiple sizes, or not?
> > The middle-end and relevant back-ends support it, but clearly not > > all the front ends. C and Ada does but your experiment seems to > > show that C++ does not. > > Does this mean that there's a bug in the C++ front end? I'd say so, but is more likely is in the ICE-on-illegal-program class.
Re: does gcc support multiple sizes, or not?
> I'd say so, but is more likely is in the ICE-on-illegal-program > class. That puts it back to the original question. Is the program legal or not? I.e. do we support multiple simultaneous pointer sizes?
Re: does gcc support multiple sizes, or not?
>That puts it back to the original question. Is the program legal or >not? I.e. do we support multiple simultaneous pointer sizes? And back to my original answer: it's up to each language to decide that. We provide the infrastructure for a language to provide it if it wants it.
Re: does gcc support multiple sizes, or not?
> And back to my original answer: it's up to each language to decide > that. Hence my original question: is it legal or not? What did the C++ developers decide?
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> And back to my original answer: it's up to each language to decide >> that. > > Hence my original question: is it legal or not? What did the C++ > developers decide? The C++ standard implies that for all pointer-to-object types have the same size and that all pointer-to-function types have the same size. (Technically, it doesn't say that that; it says that you can convert T* -> U* -> T* and get the original value.) However, nothing in the standard says that pointer-to-object types must have the same size as pointer-to-function types. In theory, I believe that G++ should permit the sizes to be different. However, as far as I know, none of the G++ developers considered that possibility, which probably means that we have made the assumption that they are all the same size at some points. I would consider places where that assumption is made to be bugs in the front end. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> The C++ standard implies that for all pointer-to-object types have the > same size and that all pointer-to-function types have the same size. > (Technically, it doesn't say that that; it says that you can convert T* > -> U* -> T* and get the original value.) Then they don't need to be the same size in most cases since usually when multiple pointer sizes are allowed, the underlying OS/RTL only uses the number of bits corresponding to the narrower size.
Re: does gcc support multiple sizes, or not?
Mark Mitchell <[EMAIL PROTECTED]> writes: | DJ Delorie wrote: | >> And back to my original answer: it's up to each language to decide | >> that. | > | > Hence my original question: is it legal or not? What did the C++ | > developers decide? | | The C++ standard implies that for all pointer-to-object types have the | same size and that all pointer-to-function types have the same size. | (Technically, it doesn't say that that; it says that you can convert T* | -> U* -> T* and get the original value.) However, nothing in the | standard says that pointer-to-object types must have the same size as | pointer-to-function types. Indeed. However, the C++ definition has been amended at the last Lillehammer meeting to allow that cast as "conditionally supported": either it is valid or it errors out. the compiler has to tell. -- Gaby
Re: does gcc support multiple sizes, or not?
> However, the C++ definition has been amended at the last Lillehammer > meeting to allow that cast as "conditionally supported": either it is > valid or it errors out. the compiler has to tell. Also, the mechanism to create multiple pointer sizes (attribute((mode))) is a GCC extension. Hence, my original question wasn't about about the C++ language supporting it, it was about *gcc* (and thus cc1plus) supporting it.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> However, the C++ definition has been amended at the last Lillehammer >> meeting to allow that cast as "conditionally supported": either it is >> valid or it errors out. the compiler has to tell. > > Also, the mechanism to create multiple pointer sizes > (attribute((mode))) is a GCC extension. I'm very suspicious of allowing users to specify this via attributes. 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 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, 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. 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. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> > DJ Delorie wrote: > >> However, the C++ definition has been amended at the last Lillehammer > >> meeting to allow that cast as "conditionally supported": either it is > >> valid or it errors out. the compiler has to tell. > > > > Also, the mechanism to create multiple pointer sizes > > (attribute((mode))) is a GCC extension. > > I'm very suspicious of allowing users to specify this via attributes. > 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. Aren't there some targets (like ia64-hpux) that support two different sizes of pointers, it also be nice to be able for the user access to them also from a high level so they can write code that can call between the two ABIs. -- Pinski
Re: does gcc support multiple sizes, or not?
Andrew Pinski wrote: > Aren't there some targets (like ia64-hpux) that support two different > sizes of pointers Those are entirely separate ABIs, controlled by a command-line option. There are not multiple pointer sizes within any single program. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
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 pointer. > 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.
Re: does gcc support multiple sizes, or not?
> Aren't there some targets (like ia64-hpux) that support two different > sizes of pointers, Heck, the i386 has ALWAYS supported multiple pointer sizes (16, 16+16, 32, and 32+16). We've just refused to pay the (high) price for supporting them.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> 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. Sorry, but I think that's far too casual. The long history of GCC extensions causing various kinds of problems is proof positive that new extensions should be added only with extreme care. We've already established the position that new extensions should come with a list of changes to the relevant language standards with the same rigor that would be used to modify the language itself. >> 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. 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. So, if you want to do this in C++, you need to work through the language standard and work out how having two distinct classes of pointers is going to work. I think that's doable, but not trivial. For example, you might make the 16-bit pointers "pointers" what the standard calls pointers, and then make the 32-bit pointers "big pointers". You could say that within a single class of pointers, all the usual pointer rules apply. Then, work through things like conversions between the two (is one direction implicit? are these static_casts or reinterpret_casts?), what mangling to use for big pointers, how to encode the types in RTTI, etc. If you really just need these things in a few places (like reset vectors), then I think you'd be better off with a __builtin_long_pointer() intrinsic (returning a 32-bit integer, not pointer) to use in the initializers. 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. There's also nothing inherently wrong with assembly code; if it's necessary to express the reset vector in assembly code, well, then, so be it. I can well see why doing it in C/C++ is nicer, but I don't think we should try to extend GNU C/C++ to encompass everything that can be done with an assembler. >> 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. Sure -- but you still have to say what the semantics are! In my opinion, "it seems to work" arguments are far too loose for making semantic changes to the C++ front end. We've been burned too many times. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> 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. Where in the standard does it say that? I could only find references to conversions to base classes. Plus, Borland C++ has had multiple sized pointers since the 80's. > 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?
Re: does gcc support multiple sizes, or not?
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 [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> 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. reinterpret_cast doesn't require that the intermediate form have the same bit pattern. On the m16c, for example, it's technically possible to convert from a 24 bit function pointer to a 16 bit pointer to that function's thunk, and back. Not *all* pointers can be converted, but pointers to functions can. Not that I'd want to write that kind of support code, but it's possible. The way I read it, "a pointer" to an object can be converted to "a pointer" to a different type of object, but as reinterpret_cast already leaves the const qualifier alone, it seems to be focusing on the object's type, not the pointer's type. IMHO, this allows the interpretation that a "pointer of a given size" to an object can be cast to a "pointer of the same size" to a different object. Thus, a "far *foo" can be cast to a "far *bar" and back. But, this has gone way past what I really needed. I didn't need to know if we *should* support multiple pointer sizes, I need to know *if* we support them, so I know which way to fix the code. If they're not supported, I'll work on failing gracefully. If they are supported, I'll fix that bug so it works. If you say C++ doesn't support them, I'll take it out and make it obvious that C++ doesn't support them, as long as C still supports them (because I use that feature a lot). I just don't want it to crash when the user does something that appears to be legal based on the gcc manual.
Re: does gcc support multiple sizes, or not?
> I'm very suspicious of allowing users to specify this via attributes. > 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 think there's some confusion here. For most back-ends, only one pointer size is supported. The only times that back-ends support alternate pointer sizes are in cases where we have a 64-bit machine but the OS/RTL only uses 32 bits for pointers. Alpha/VMS is an example of this. In those cases, you often have circumstances where some "external" interfaces (e.g., to OS or RTL) has structures with 32-bit pointers and others has 64-bit pointers. So you need to be able to express the interfaces to both of these and that requires both pointer sizes. This is not intended for "random" programmer usage.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> 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. > > reinterpret_cast doesn't require that the intermediate form have the > same bit pattern. Exactly so. However, all valid pointers must be handles, so unless the 32-bit address space is "sparse", something will go wrong. > The way I read it, "a pointer" to an object can be converted to "a > pointer" to a different type of object, but as reinterpret_cast > already leaves the const qualifier alone, it seems to be focusing on > the object's type, not the pointer's type. There's no distinction in ISO C++; every object type has exactly one associated pointer type. The point of reinterpret_cast is to let you convert A* to B* where A and B are unrelated object types. It's an operation on pointers, not general objects; for example, you can't do "reinterpret_cast(7)", but you can do "reinterpret_cast((int*)0))". > If you say C++ doesn't support them, I'll take it out and make it > obvious that C++ doesn't support them, as long as C still supports > them (because I use that feature a lot). I just don't want it to > crash when the user does something that appears to be legal based on > the gcc manual. Good call. I don't feel qualified to comment for C, but for C++, I think it's correct to say that we don't support them. I think we *could* support them, in theory, but that would be a good bit of work. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
Richard Kenner wrote: >> I'm very suspicious of allowing users to specify this via attributes. >> 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 think there's some confusion here. > So you need to be able to express the interfaces to both of these and > that requires both pointer sizes. The confusion is perhaps that you're thinking that my statement that we need to specify the semantics is clearly implies that I don't think it's a useful feature? I do think it's a useful feature, but I also think that you can't just drop it into C++ without thinking about all the consequences of that action. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> The confusion is perhaps that you're thinking that my statement that we > need to specify the semantics is clearly implies that I don't think it's > a useful feature? I do think it's a useful feature, but I also think > that you can't just drop it into C++ without thinking about all the > consequences of that action. Sure. However, I wasn't addressing the usefulness issue but rather the semantic issue of whether you lose data when converting a pointer from 64- to 32-bit by saying that the cases for which this extension is intended are such where that can't happen.
Re: does gcc support multiple sizes, or not?
> > reinterpret_cast doesn't require that the intermediate form have the > > same bit pattern. > > Exactly so. However, all valid pointers must be handles, so unless the > 32-bit address space is "sparse", something will go wrong. I would go so far as to say that it's defined (hence supported) if the intermediate form is at least as many bits as the other types.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >>> reinterpret_cast doesn't require that the intermediate form have the >>> same bit pattern. >> Exactly so. However, all valid pointers must be handles, so unless the >> 32-bit address space is "sparse", something will go wrong. I didn't help things here by saying "handles"; I meant "handled". Sorry! > I would go so far as to say that it's defined (hence supported) if the > intermediate form is at least as many bits as the other types. I'm not sure if I understand. In ISO C++, it would be fine for "char *" to have more bits than all other pointers. The standard says X* -> Y* -> X* is value-preserving if Y has no stricter alignment than X. Since "char" has weak alignment requirements, Y can be "char". Is that what you mean? In ISO C++, there's of course no notion of "char *far" or "char *near"; there's just "char *". So, there's no way to directly map your intended type system onto the conversion sequence above. The spirit of the standard would seem to be that "X* near" -> "X* far" -> "X* near" be value-preserving, but to make no guarantees about "X* far" -> "X* near" -> "X* far". -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: does gcc support multiple sizes, or not?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Mark Mitchell > Sent: Monday, August 14, 2006 12:50 PM > To: DJ Delorie > Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org > Subject: Re: does gcc support multiple sizes, or not? > > DJ Delorie wrote: > >> And back to my original answer: it's up to each language to decide > >> that. > > > > Hence my original question: is it legal or not? What did the C++ > > developers decide? > > The C++ standard implies that for all pointer-to-object types have the > same size and that all pointer-to-function types have the same size. > (Technically, it doesn't say that that; it says that you can convert T* > -> U* -> T* and get the original value.) However, nothing in the > standard says that pointer-to-object types must have the same size as > pointer-to-function types. The C standard says that all pointer to structure and unions must have the same size and format as each other, since otherwise declaring pointers to structure tags that aren't declared in this module would not be compatible with the same declaration in another module where you do declare the structure tag. When the ANSI C-89 (and later ISO C-90) standard came out, I was working on a C compiler for a machine with different flavors of pointers, and so I was very aware of the ins and outs. Pointers to functions can be a different size than pointers to data, which is one of the reasons in C-89 you can't assign a function pointer to a void *. Because of the rule for functions with no prototypes (since deprecated in C-99), all function pointers must be the same size as each other. > In theory, I believe that G++ should permit the sizes to be different. > However, as far as I know, none of the G++ developers considered that > possibility, which probably means that we have made the assumption that > they are all the same size at some points. I would consider places > where that assumption is made to be bugs in the front end. I think having pointers be the same size is ingrained in the whole compiler, not just the front ends. I did a port to a machine (Mitsubshi D10V) that had different flavors of pointers, though thankfully they were the same size (pointers to functions were pointers to 32-bit instruction words, while pointers to data were bytes to 8-bit bytes). When I did that compiler (GCC 2-3 time frame), there were many limitations caused by this, including the prohibition against trampolines. -- Michael Meissner AMD, MS 83-29 90 Central Street Boxborough, MA 01719
Re: does gcc support multiple sizes, or not?
> I think having pointers be the same size is ingrained in the whole > compiler, not just the front ends. Having *implicit* pointers be *a specific* size certainly is. Made the m32c project a lot harder. There's a lot of places that use POINTER_SIZE instead of MODE_SIZE(x), or Pmode instead of GET_MODE (x), even when doing the "right" thing would be trivial.
Re: does gcc support multiple sizes, or not?
> I'm not sure if I understand. In ISO C++, it would be fine for "char *"
> to have more bits than all other pointers. The standard says X* -> Y*
> -> X* is value-preserving if Y has no stricter alignment than X. Since
> "char" has weak alignment requirements, Y can be "char". Is that what
> you mean?
No, I meant if we go A -> B -> A, it's defined iff sizeof(B) >= sizeof(A)
> In ISO C++, there's of course no notion of "char *far" or "char
> *near"; there's just "char *". So, there's no way to directly map
> your intended type system onto the conversion sequence above.
The problem seems to revolve around casts. How about if I turn the
abort into a useful message about casting between pointer sizes, and
require the user to use a builtin to convert pointers? In the case of
TPF, a "normal" cast wouldn't do the right thing anyway. Of course,
we should make C give a similar warning, so as to not surprise users.
I strongly request we continue supporting the use of attribute((mode))
to create pointers of different sizes, at least for copying and
passing. The m32c reset vector and interrupt table really want to be
set up like this example:
typedef void (*ifunc)() __attribute__((mode(SI)));
ifunc __attribute__((section(".resetvec"))) reset_vector = start;
extern ifunc ivects[];
ivects[i] = dummy_handler;
memcpy(ivects+1, ivects, 63*4);
if (...)
ivects[A0_VEC] = timer_a0_handler;
if (...)
ivects[A1_VEC] = timer_a1_handler;
It seems like there are plenty of examples of OSs which would benefit
from an easy way to manage nondefault pointer sizes, even if we can't
use them for everything a default pointer can be used for.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote:
> I strongly request we continue supporting the use of attribute((mode))
> to create pointers of different sizes, at least for copying and
> passing. The m32c reset vector and interrupt table really want to be
> set up like this example:
>
> typedef void (*ifunc)() __attribute__((mode(SI)));
> ifunc __attribute__((section(".resetvec"))) reset_vector = start;
Maybe it is just me, but it seems more natural to have:
typedef void (*long ifunc)();
i.e. in C or C++ have:
int *stdptr;
int *short ptr16bits;
int *long ptr64bits;
like:
int *const constptr;
int *volatile volatileptr;
I am not sure about authorising dereferencing of short pointers or only
use them when associated to a standard pointer - like:
typedef void (*short func_t)();
func_t array_of_func_ptr[32];
void (*base)();
and then:
(*base + array_of_func_ptr[i]) ();
But short pointer have a use (reduce array size of pointers to local objects),
exist on ia32/ia16 instruction set, and are the only pointer loaded atomic-ally
in PPC (and other RISCs) (std pointers loaded by "lis r1,[EMAIL PROTECTED] ;
addi r1,[EMAIL PROTECTED] "),
so basic data structures (queues, stacks) are a lot easier to implement when
the
size is limited to 64 Kbytes.
The short pointer may also be used as the difference in between two pointers,
by a cast when the programmer knows the difference will fit:
int array[100], *ptr1 = &array[10], *ptr2 = &array[20];
int *short diffptr = (int *short)(ptr2 - ptr1);
The result of converting an "int *" to a "int *short" with a too big value
should
be the same as converting an "int" to a "short int" with a too big value.
Sorry, just 2 cent ideas without implementation...
Etienne.
p4.vert.ukl.yahoo.com uncompressed/chunked Wed Aug 16 13:14:16 GMT 2006
___
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet
!
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos
expériences.
http://fr.answers.yahoo.com
Re: does gcc support multiple sizes, or not?
> > typedef void (*ifunc)() __attribute__((mode(SI)));
> > ifunc __attribute__((section(".resetvec"))) reset_vector = start;
>
> Maybe it is just me, but it seems more natural to have:
> typedef void (*long ifunc)();
You can use #defines to make it pretty:
#define far __attribute__((mode(SI)))
typedef void (* far ifunc)();
extern ifunc ivects[];
> But short pointer have a use (reduce array size of pointers to
> local objects),
I think you'll find that implementing this is much more of a project
that what I need long/short pointers for. You want multiple *default*
pointer sizes; I just want an exception that the programmer can use
for odd cases.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: > The problem seems to revolve around casts. How about if I turn the > abort into a useful message about casting between pointer sizes, and > require the user to use a builtin to convert pointers? That's a good start -- but, at the very least, you still have to say what happens for type_info and define name-mangling. Your suggestion isn't going to be easy to implement, either; the front end probably has lots of places where it handles, for example, implicit conversions from Derived* to Base*, and it's going to be looking at the types of the pointed-to objects, but all it's going to check for the pointer types is that they are in fact POINTER_TYPE nodes. I think you really have to accept that the change you want to make goes to a relatively fundamental invariant of C++. It's not something you can do correctly as a quick change; you have to think through all the consequences. I'll again point out that in your reset-vector example you don't actually need any pointer operations. You could just as well do: typedef int ifunc __attribute__((mode(SI)); vects[A0_VEC] = __builtin_pointer32 (timer_a0_handler); I think you should consider that solution. It's not as pretty, for the programmer, but it's a lot less problematic from a language point of view. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> I'll again point out that in your reset-vector example you don't > actually need any pointer operations. I'm not trying to dereference any of these nonstandard pointers. I just need to do all the other things - assignment, copy, storage, cast to/from integers, etc. Rarely, calling a function indirectly, but that would have to be specific to the target, and documented therein. These are the kinds of things that are often needed for interfacing to odd hardware or OS ABIs. To make nonstandard sized pointers "first class pointers", i.e. allowing dereferencing in all cases, is a MUCH harder problem, which even cc1 doesn't even come close to solving. This is a different rant, too, which I've done before.
Re: does gcc support multiple sizes, or not?
> vects[A0_VEC] = __builtin_pointer32 (timer_a0_handler); Note that the builtin would be needed for run-time conversion between pointers of different sizes, i.e. casts. Why? Well, gcc doesn't "just know" how to do such conversions. For example, TPF has a 31 bit address. To convert it to 64, you clear the MSB and zero extend. To convert back, you truncate and set the MSB (if you clear the MSB, you end up with a 24 bit address, it's a "size flag"). In theory, 64 bit addresses should always have the LSB set too. But a compile-time assigment of a symbol to a pointer should "just work" as long as the assembler supports it (I fixed that bug some months ago).
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> I'll again point out that in your reset-vector example you don't >> actually need any pointer operations. > > I'm not trying to dereference any of these nonstandard pointers. Good! In that case, you don't need them to be pointers at all. :-) I think you should just declare them as integer types. (You can give them pointer-sounding typedef names.) Then, provide builtins for converting to/from real pointers. The other things: > assignment, copy, storage, cast to/from integers, etc. will then just work. > Rarely, calling a function indirectly, but > that would have to be specific to the target, and documented therein. Again, a built-in will work here. If you avoid trying to introduce multiple *pointer* types, and just treat these things as *integer* types, you avoid all of the hard language issues. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: > But a compile-time assigment of a symbol to a pointer should "just > work" as long as the assembler supports it (I fixed that bug some > months ago). There's no reason you can't make the built-in automatically folded by the front-end so that you still get a constant expression. I understand that this isn't the syntax you write, in that you have to write: static ptr32_t x = __builtin_ptr32 (f); instead of: static void (*far x)() = f; but I think you're much more likely to actually get the built-in approach to work correctly in C++. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> Good! In that case, you don't need them to be pointers at all. :-) > > I think you should just declare them as integer types. That makes initializing function pointers messy. Besides, they're not integers. They're pointers. I'd *like* to be able to dereference them in some simple ways in the future; telling me to "just use integers" is a step backwards. Why don't I "just use assembler" or "just use C"? that defeats the whole purpose of having a high level language.
Re: does gcc support multiple sizes, or not?
> but I think you're much more likely to actually get the built-in > approach to work correctly in C++. But... initializing function pointers already works, without builtins. Initializing an N bit pointer from an N bit integer now works with a cast. Copying an N bit pointer to another N bit pointer works. The only part that needs a builtin at this point is runtime conversion of pointer values, at least to specify sign or zero extension. That, and dereferencing. I see no value in adding a builtin for something that already works just fine without a builtin.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> Good! In that case, you don't need them to be pointers at all. :-) >> >> I think you should just declare them as integer types. > > That makes initializing function pointers messy. > > Besides, they're not integers. They're pointers. I'd *like* to be > able to dereference them in some simple ways in the future; telling me > to "just use integers" is a step backwards. Why don't I "just use > assembler" or "just use C"? that defeats the whole purpose of having > a high level language. I think we're going to have to agree to disagree. Sure, it would be nice if these things were pointers. I'd be happy to see a specification for how these alternative pointers work, and I'd be happy to consider a patch that made a serious stab at implementing that specification. However, I will reject any patch to support these alternative pointers in C++ until all the language issues have been resolved. I'm strongly opposed to adding more extensions to GNU C++ without thinking through all of their implications. We've suffered far too much pain for far too many years because of doing precisely this in the past. I would also argue against this extension in C at this point because users expect GNU C extensions to work in C++ as well. However, I think it would be presumptuous for me to try to reject supporting these pointers in GNU C; that's for the C maintainers to say. Since you seem to be hesitant (and, reasonably so, in my opinion!) to work on the language-design issues for C++, I would recommend the integer approach as a way of providing the functionality you need in the short term. Sorry, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> Sure, it would be nice if these things were pointers. At the moment, they are. > However, I will reject any patch to support these alternative > pointers in C++ until all the language issues have been resolved. At the moment, there are no language issues to resolve. The only thing people were arguing about was the semantics of casting, and I agreed to using a builtin (because a plain cast won't work anyway). Everything else, except dereferencing and "implied pointers" (i.e. passing a reference, the '&' operator, etc), works just fine without any patches, so there's nothing to reject. It would be nice if dereferencing an odd pointer worked. It would definitely require target work, and probably MI work as well. I'm assuming that "dereferencing a pointer" is well defined regardless of the size of the pointer, at least at the language level. > Since you seem to be hesitant (and, reasonably so, in my opinion!) > to work on the language-design issues for C++, The remaining problems aren't really "language issues". The major problems are in the middle-end code, like optimizers, which blindly create pointers of size POINTER_SIZE when they take the address of things. The only language issue, other than C++'s "all pointers are the same size" rule, is that the target needs to participate a little more when one takes the address of something. It already participates a little, to provide alignment information. A full implementation - which I'm not asking for at this time - would need a hook to let the target generate the "address of objects" rather than have gcc blindly create a Pmode address. For example, if you declare a variable with "far" attribute, the backend doesn't get the chance to make the SYMBOL_REF :SI (for m32c) or :DI (for tpf), and if you hack that in anyway, other parts of gcc ignore it and change it to :Pmode.
Re: does gcc support multiple sizes, or not?
DJ Delorie <[EMAIL PROTECTED]> writes: | > Good! In that case, you don't need them to be pointers at all. :-) | > | > I think you should just declare them as integer types. | | That makes initializing function pointers messy. | | Besides, they're not integers. They're pointers. I'd *like* to be | able to dereference them in some simple ways in the future; telling me | to "just use integers" is a step backwards. I'm lost. In previous message, you said # I'm not trying to dereference any of these nonstandard pointers. | Why don't I "just use assembler" or "just use C"? that defeats the | whole purpose of having a high level language. I'm not sure that reasoning will advance the issue. The points raised by Mark are very important ones. They should not be hand-waved. -- Gaby
Re: does gcc support multiple sizes, or not?
> # I'm not trying to dereference any of these nonstandard pointers. Not *now*. I'd like to in the future.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: > At the moment, there are no language issues to resolve. No, rather, at the moment there is a class of programs which are accidentally accepted by the C++ front end and happen to do some of the things that you want. That is different from saying that the compiler supports the feature that you want. This is an undocumented extension. Note that the documentation for the mode attribute says: "This in effect lets you request an integer or floating point type according to its width." (It does not say pointer type.) It then goes on to say "and `pointer' or `__pointer__' for the mode used to represent pointers". The use of the definite article indicates that there is in fact only one mode for pointers. > The remaining problems aren't really "language issues". I'm surprised that you believe this, in view of the concrete examples I've given. I'm not sure how to convince you that there's anything non-trivial to do here, but there is. So, unfortunately, I'm stuck: all I can do is tell you that the fact that this current works at all in C++ is an accident, might go away at any point, and probably violates various assumptions in the front end. If you're willing to use integers, you'll have an easy time. If you want the more elegant language semantics of multiple pointer sizes, you'll have to take the time to read through the C++ standard and think about all the potential impact of the extension you're proposing. Or, you can decide to work on the middle end issues, try to get your patches accepted, and then come back to the front end issues later. I don't have any plans to aggressively go reject this code in the C++ front end, but I would vaguely like to clean up and specify how attributes interact with C++ in more detail, and that might result in problems for this usage. (We really need to specify how attributes interact with same-typed-ness, implicit conversions, etc.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Aug 17, 2006 at 07:35:58AM -0700, Mark Mitchell wrote: > If you're willing to use integers, you'll have an easy time. If you > want the more elegant language semantics of multiple pointer sizes, > you'll have to take the time to read through the C++ standard and think > about all the potential impact of the extension you're proposing. Or, > you can decide to work on the middle end issues, try to get your patches > accepted, and then come back to the front end issues later. May I jog your memory about "named address spaces". Are "near" and "far" pointers something that might be able to be shoehorned into any [future] infrastructure for supporting these named address spaces? Same for DJ's oddball pointers - could they fit? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/ iD8DBQFE5IYnwyMv24BBd/gRAgJ1AJ9IVFM7cmRZy4G71F+ZIvqSr9l0ogCfZn2f +6MHu9ROUo9RKj14Rew0W4U= =ChKv -END PGP SIGNATURE-
Re: does gcc support multiple sizes, or not?
Bernd Jendrissek wrote: > May I jog your memory about "named address spaces". Are "near" and > "far" pointers something that might be able to be shoehorned into any > [future] infrastructure for supporting these named address spaces? Same > for DJ's oddball pointers - could they fit? Maybe so -- but that's another can of worms from a language design point of view... -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
Mark Mitchell wrote: >I think you really have to accept that the change you want to make goes >to a relatively fundamental invariant of C++. I don't see how you can call this a realatively fundamental invariant of C++, given how various C++ implementations have supported multiple pointer sizes for much of the history of C++. Perhaps you could argue that Standard C++ made a fundamental change to the language, but I don't think so. The original STL made specific allowances for different memory models and pointer types, and this design, with it's otherwise unnecessary "pointer" and "size_type" types, was incorporated in to the standard. I think the intent of the "(T *)(U *)(T *)x == (T *)x" invariant was only to limit the standard pointer types, not make to non-standard pointer types of differt size fundamentally not C++. (Unlike, say, the fundamental changes the standard made to how templates work...) Ross Ridge
