| Lynn McGuire <lynnmcguire5@gmail.com>: Aug 30 09:59PM -0500 On 8/29/2021 1:57 PM, Alf P. Steinbach wrote: > Are there any examples of current platforms/architectures where > sizeof(void*) > sizeof(int*) ? > - Alf Are there any old platforms where this was the case also ? Lynn |
| Siri Cruise <chine.bleu@yahoo.com>: Aug 30 09:23PM -0700 In article <sgglb9$c02$1@dont-email.me>, > Are there any examples of current platforms/architectures where > sizeof(void*) > sizeof(int*) ? sizeof(void*) <= sizeof(intptr_t) That's sort of the point of having intptr_t. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \ I am an Andrea Doria sockpuppet. insults Islam. Mohammed |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Aug 30 09:53PM -0700 On 8/30/2021 7:59 PM, Lynn McGuire wrote: >> - Alf > Are there any old platforms where this was the case also ? > Lynn Quoted from SO https://stackoverflow.com/questions/24867814/printfp-and-casting-to-void/24867850#24867850 === An example of an implementation with different pointer types representation is Cray PVP where the representation of pointer types is 64-bit for `void *` and `char *` but 32-bit for the other pointer types. See "Cray C/C++ Reference Manual", Table 3. in "9.1.2.2" http://docs.cray.com/books/004-2179-003/004-2179-003-manual.pdf === -- Best regards, Andrey Tarasevich |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Aug 30 09:59PM -0700 On 8/30/2021 9:53 PM, Andrey Tarasevich wrote: > See "Cray C/C++ Reference Manual", Table 3. in "9.1.2.2" > http://docs.cray.com/books/004-2179-003/004-2179-003-manual.pdf > === The link to the Reference Manual is broken, but the same manual is currently available from here https://manualzz.com/doc/13740819/cray-c-c---reference-manual-004–2179–003 Also, 32 bits were apparently used in value representation of those "other pointer types", while the object representation was still the same 64 bits, implying 32 padding bits. -- Best regards, Andrey Tarasevich |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 30 11:29PM -0700 >> sizeof(void*) > sizeof(int*) ? > sizeof(void*) <= sizeof(intptr_t) > That's sort of the point of having intptr_t. That's not guaranteed. What is guaranteed is that converting a void* to intptr_t and back again yields a value that compares equal to the original (if intptr_t exists). If void* has bits that do not contribute to its representation (basically padding bits, but I believe the standard uses that term only for integer types), then it's possible that intptr_t could be smaller than void*. It's unlikely, though. Also, how is that relevant to the original question? -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Bo Persson <bo@bo-persson.se>: Aug 31 09:01AM +0200 On 2021-08-31 at 04:59, Lynn McGuire wrote: >> - Alf > Are there any old platforms where this was the case also ? > Lynn It would have been word-addressed machines, where char* (and thus void*) needed a part-word indicator in addition to the word address. Haven't seen any of those lately. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 31 03:00AM -0700 On Tuesday, 31 August 2021 at 10:01:56 UTC+3, Bo Persson wrote: > It would have been word-addressed machines, where char* (and thus void*) > needed a part-word indicator in addition to the word address. > Haven't seen any of those lately. I have never heard of C++ (conforming to any of standards) implemented (or ported) for any of those. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 12:27PM +0200 Am 29.08.2021 um 20:57 schrieb Alf P. Steinbach: > Are there any examples of current platforms/architectures where > sizeof(void*) > sizeof(int*) ? Why should there be such an architecture ? On such an architecture you won't be able to cast the result of malloc() to an int * |
| Richard Damon <Richard@Damon-Family.org>: Aug 31 07:37AM -0400 On 8/31/21 6:27 AM, Bonita Montero wrote: > Why should there be such an architecture ? > On such an architecture you won't be able > to cast the result of malloc() to an int * No, on those machines you could still do the cast. The key is that the void* (and char*) pointer had extra bits to indicate which character within the int was pointed at, and the cast would just throw away those bits. It says that a pointer that wasn't aligned properly for an int might change if converted to an int*, but malloc() will always return a pointer that is properly aligned, so the conversion is safe. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 02:14PM +0200 Am 31.08.2021 um 13:37 schrieb Richard Damon: > It says that a pointer that wasn't aligned properly for an int might > change if converted to an int*, but malloc() will always return a > pointer that is properly aligned, so the conversion is safe. Tell me an architecture with that properties or tell me how propable it is that there will be ever such an architecture. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Aug 31 07:06AM -0700 On Tuesday, August 31, 2021 at 8:14:52 AM UTC-4, Bonita Montero wrote: > > pointer that is properly aligned, so the conversion is safe. > Tell me an architecture with that properties or tell me how propable > it is that there will be ever such an architecture. The probability is 1 - such architectures already existed at the time the first C standard was written. It was precisely the desire to allow a fully conforming implementation of C on such a machine that led the C committee to deliberately avoid imposing any requirements that would make such an implementation non-conforming, and the C++ committee chose to follow suit. I unfortunately, cannot provide any examples - I know about such machines only from second- and third-hand accounts. The relevant clause from the C standard, which is incorporated by reference into the C++ standard, says "The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated)." (7.22.3p1). Because it must be aligned for any object, it must, in particular, be word- aligned on architectures such as the one described. Therefore, conversion of the void* value returned by malloc() to int* can safely discard the bits containing the byte offset within a word, since that byte offset is guaranteed to be 0. In general, conversion from void* to int* will be lossy on such a machine, but only for pointers that are not word-aligned, and the C standard allows for that possibility. For such a conversion "If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined." (6.3.2.3p7). My experience with the C++ standard suggests that it probably has wording that is equivalent to 6.3.2.3p7 from the C standard, at least for code that doesn't make any use of C++-specific features. However, during a quick search I haven't been able to locate it, probably because it is worded quite differently. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 31 10:08AM -0400 On 8/30/21 10:59 PM, Lynn McGuire wrote: >> sizeof(void*) > sizeof(int*) ? >> - Alf > Are there any old platforms where this was the case also ? My understanding is that it was precisely the existence of such platforms that motivated the standard's failure to prohibit such implementations. Specifically, platforms where the word size was bigger than the byte size, so that if _Alignof(T) was greater than or equal to the word size, T* simply contains a number identifying which word it starts in, while if _Alignof(T) is less than the word size, T* contains both a word number and a byte offset within the word. However, while I have heard of such platforms, I can't personally vouch for the existence any specific platform like that. Note: I'm not sure whether any such platform has ever had a C implementation that supported _Alignof(), I'm just using _Alignof(T) as shorthand for "the alignment requirement of type T". The concept of an alignment requirement predates _Alignof() by several decades. |
| scott@slp53.sl.home (Scott Lurndal): Aug 31 02:54PM >both a word number and a byte offset within the word. >However, while I have heard of such platforms, I can't personally vouch >for the existence any specific platform like that. The only one I can think of is the 48-bit word Burroughs Large Systems (e.g. B5[57]00 and successors), which still exist as the Unisys Clearpath systems (albeit emulated rather than custom CMOS in current generations). https://public.support.unisys.com/aseries/docs/clearpath-mcp-17.0/pdf/86002268-206.pdf |
| scott@slp53.sl.home (Scott Lurndal): Aug 31 03:00PM >the word size, T* simply contains a number identifying which word it >starts in, while if _Alignof(T) is less than the word size, T* contains >both a word number and a byte offset within the word. From the Unisys C compiler manual: A null pointer constant of any type can be converted to any pointer type. It is still recognized as a null pointer. With this C compiler, the conversion does not change its representation. A null pointer is a pointer that never points to any object or function. A pointer to an object of one type can be converted to a pointer to an object of another type by use of an explicit cast. The explicit cast is not necessary if one pointer is a pointer to void. The resulting pointer might not be valid if it is improperly aligned for the type of object pointed to. It is always true that a pointer to an object of a given alignment can be converted to a pointer to an object of a less strict alignment and back again without change. (An object that has type char has the least strict alignment.) The following cannot be converted: · "pointer to function" to "pointer to object" · "pointer to object" to "pointer to function" · "pointer to function" to "pointer to voidö · "pointer to voidö to "pointer to function" See Also Refer to "Cast Operator" in Section 5 for more information. All integer/floating types occupy a full 48-bit word except for char, which can point to any one of the six bytes within a 48-bit word. |
| scott@slp53.sl.home (Scott Lurndal): Aug 31 03:02PM >Am 31.08.2021 um 13:37 schrieb Richard Damon: >Tell me an architecture with that properties or tell me how propable >it is that there will be ever such an architecture. Probability is 100%. See Unisys Clearpath C compiler reference manual. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 05:20PM +0200 Nothing read of what you wrote. I don't like unrealistic assumptions which weren't been true for decades ands which will never be true again. |
| scott@slp53.sl.home (Scott Lurndal): Aug 31 03:36PM >Nothing read of what you wrote. I don't like unrealistic assumptions >which weren't been true for decades ands which will never be true >again. Ah, but they will be true again, in just year or two as CHERI migrates into mainstream processors. Und wen interessiert es überhaupt, was Sie denken? |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 05:44PM +0200 Am 31.08.2021 um 17:36 schrieb Scott Lurndal: >> again. > Ah, but they will be true again, in just year or two as > CHERI migrates into mainstream processors. You're a kind of person a lot of uncertainties. And such person overestimate the likehood of these uncertainties in the real world. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Aug 31 09:12AM -0700 On Tuesday, August 31, 2021 at 11:20:47 AM UTC-4, Bonita Montero wrote: > Nothing read of what you wrote. I don't like unrealistic assumptions > which weren't been true for decades ands which will never be true > again. As you failed to cite the message you're responding to, I have no idea which one it was. Your first sentence isn't a valid English sentence - I presume that you meant "I've read nothing of what you wrote."? If so, then how do you know whether or not it contained "unrealistic assumptions"? What's unrealistic about assumptions that have been true in the past, and may (as Scott pointed out) become true again in the future? Your most fundamental problem is that you don't believe that any implementation ever has or ever could exist that is significantly different from the limited variety of systems that you personally have had experience with. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 06:20PM +0200 > Your most fundamental problem is that you don't believe that any > implementation ever has or ever could exist that is significantly different from > the limited variety of systems that you personally have had experience with. There's no good reason to implement today a CPU which beaves incom- patible to the assumptions I suggested which are safe to rely on. |
| scott@slp53.sl.home (Scott Lurndal): Aug 31 04:40PM >> the limited variety of systems that you personally have had experience with. >There's no good reason to implement today a CPU which beaves incom- >patible to the assumptions I suggested which are safe to rely on. As someone whose day job is designing CPUs, I find your naivete amusing. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 07:04PM +0200 Am 31.08.2021 um 18:40 schrieb Scott Lurndal: >> patible to the assumptions I suggested which are safe to rely on. > As someone whose day job is designing CPUs, I find your naivete > amusing. There is no person designing such CPUs today and there will never be. |
| "see.my....@gmail.com" <see.my.homepage@gmail.com>: Aug 31 10:26AM -0700 > Why should there be such an architecture ? > On such an architecture you won't be able > to cast the result of malloc() to an int * There is no promise in the standard that malloc() operates on full address space, pointer-wise. I can *imagine* a platform where malloc() returns a pointer from a pool that is a fraction of the whole address space, which would allow this cast to work fine. Note that this is completely independent on the word-alignment considerations. Now, you might not be very happy with such an implementation, but actual platforms where a subset of address space was actually used, or with some form of partitioning, segmenting, windowing, region mapping, banking or whatever, exist(ed) both on desktop and in embedded worlds. The fact that a large fraction of "production code" would break into pieces in such a case is another story. :-) -- Maciej Sobczak * http://www.inspirel.com |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 07:46PM +0200 >> On such an architecture you won't be able >> to cast the result of malloc() to an int * > There is no promise in the standard that malloc() operates on full address space, pointer-wise. I can *imagine* a platform where malloc() returns a pointer from a pool that is a fraction of the whole address space, which would allow this cast to work fine. Note that this is completely independent on the word-alignment considerations. This wouldn't affect that you always can assign the result of malloc() to an int *. So completely different discussion. |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 31 09:37PM +0100 On 31/08/2021 18:04, Bonita Montero wrote: > There is no person designing such CPUs today and there will never be. Never is a long time. I've worked on systems where the difference between two addresses is 1 bit, and 36 bits, and several values in between. The 1 bit was a GPU which had hardware support for variables of arbitrary numbers of bits. Very handy for our 3 bit pixels. And yes, we ran C on it. The 36 bit one is dead, and didn't AFAIK run C. Andy |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment