Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ?

333 views
Skip to first unread message

Alf P. Steinbach

unread,
Aug 29, 2021, 2:58:01 PMAug 29
to
Are there any examples of current platforms/architectures where
sizeof(void*) > sizeof(int*) ?

- Alf

Lynn McGuire

unread,
Aug 30, 2021, 11:00:10 PMAug 30
to
Are there any old platforms where this was the case also ?

Lynn

Siri Cruise

unread,
Aug 31, 2021, 12:24:02 AMAug 31
to
In article <sgglb9$c02$1...@dont-email.me>,
"Alf P. Steinbach" <alf.p.s...@gmail.com> wrote:

> 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

unread,
Aug 31, 2021, 12:53:48 AMAug 31
to
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

unread,
Aug 31, 2021, 12:59:22 AMAug 31
to
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.

Keith Thompson

unread,
Aug 31, 2021, 2:30:11 AMAug 31
to
Siri Cruise <chine...@yahoo.com> writes:
> In article <sgglb9$c02$1...@dont-email.me>,
> "Alf P. Steinbach" <alf.p.s...@gmail.com> wrote:
>
>> 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.

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.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bo Persson

unread,
Aug 31, 2021, 3:01:56 AMAug 31
to
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

unread,
Aug 31, 2021, 6:00:22 AMAug 31
to
I have never heard of C++ (conforming to any of standards) implemented
(or ported) for any of those.

Bonita Montero

unread,
Aug 31, 2021, 6:27:36 AMAug 31
to
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

unread,
Aug 31, 2021, 7:37:46 AMAug 31
to
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

unread,
Aug 31, 2021, 8:14:52 AMAug 31
to
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

unread,
Aug 31, 2021, 10:06:42 AMAug 31
to
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

unread,
Aug 31, 2021, 10:08:24 AMAug 31
to
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 Lurndal

unread,
Aug 31, 2021, 10:54:43 AMAug 31
to
James Kuyper <james...@alumni.caltech.edu> writes:
>On 8/30/21 10:59 PM, Lynn McGuire wrote:
>> 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 ?
>
>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.

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 Lurndal

unread,
Aug 31, 2021, 11:01:14 AMAug 31
to
James Kuyper <james...@alumni.caltech.edu> writes:
>On 8/30/21 10:59 PM, Lynn McGuire wrote:
>> 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 ?
>
>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.

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 Lurndal

unread,
Aug 31, 2021, 11:02:53 AMAug 31
to
Probability is 100%. See Unisys Clearpath C compiler reference
manual.

Bonita Montero

unread,
Aug 31, 2021, 11:20:47 AMAug 31
to
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 Lurndal

unread,
Aug 31, 2021, 11:36:51 AMAug 31
to
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

unread,
Aug 31, 2021, 11:44:29 AMAug 31
to
Am 31.08.2021 um 17:36 schrieb Scott Lurndal:
> Bonita Montero <Bonita....@gmail.com> writes:
>> 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.

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

unread,
Aug 31, 2021, 12:12:55 PMAug 31
to
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

unread,
Aug 31, 2021, 12:20:31 PMAug 31
to
Am 31.08.2021 um 18:12 schrieb james...@alumni.caltech.edu:

> 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 Lurndal

unread,
Aug 31, 2021, 12:40:43 PMAug 31
to
As someone whose day job is designing CPUs, I find your naivete
amusing.

Bonita Montero

unread,
Aug 31, 2021, 1:04:27 PMAug 31
to
There is no person designing such CPUs today and there will never be.

see.my....@gmail.com

unread,
Aug 31, 2021, 1:26:41 PMAug 31
to
> > 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 *

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

unread,
Aug 31, 2021, 1:46:30 PMAug 31
to
Am 31.08.2021 um 19:26 schrieb see.my....@gmail.com:
>>> 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 *
>
> 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

unread,
Aug 31, 2021, 4:37:51 PMAug 31
to
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

Juha Nieminen

unread,
Sep 1, 2021, 12:40:58 AMSep 1
to
You asked a question, your question was answered, and you respond like
this. Why? What do you have to gain from acting like this? It's almost
like you deliberately want people to think that you are an asshole.
But why? Is it some kind of self-destructive behavior?

Juha Nieminen

unread,
Sep 1, 2021, 12:43:03 AMSep 1
to
Why not? If void* is larger than int*, why couldn't you cast a
void* to an int*?

Lynn McGuire

unread,
Sep 1, 2021, 12:46:46 AMSep 1
to
Yeah, can't think of a reason why to build anything other than a byte
addressable machine. I don't even see expansion of the byte from 8 bits
to 16 bits.

Lynn

Bonita Montero

unread,
Sep 1, 2021, 1:25:40 AMSep 1
to
Am 31.08.2021 um 22:37 schrieb Vir Campestris:
> 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.

That must be decades ago.
And currently and in the future no one designs such silly CPUs.

Bonita Montero

unread,
Sep 1, 2021, 1:26:49 AMSep 1
to
Because it would drop information and f.e. you won't be able to
access the int-arrray behind the int *.

Christian Gollwitzer

unread,
Sep 1, 2021, 1:42:16 AMSep 1
to
Am 01.09.21 um 07:26 schrieb Bonita Montero:
I think you misunderstand how that works. The int pointer would not
count in bytes, but in ints. So if you do ptr++, then it would actually
increase by 1 - not by 4 or 8 as it does on the usual platforms, where
there is no difference between int*, char*, void* on the machine code level.

Casting void* to int* would be a right shift, and if the void* points
inside "half an int", that would be an error - but malloc would be
constructed such that it only ever returns an int-aligned address.
Because the CPU on these platforms can work with aligned ints only.

Christian

Bonita Montero

unread,
Sep 1, 2021, 2:04:11 AMSep 1
to
Am 01.09.2021 um 07:41 schrieb Christian Gollwitzer:
> Am 01.09.21 um 07:26 schrieb Bonita Montero:
>> Am 01.09.2021 um 06:42 schrieb Juha Nieminen:
>>> Bonita Montero <Bonita....@gmail.com> wrote:
>>>> 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 *
>>>
>>> Why not? If void* is larger than int*, why couldn't you cast a
>>> void* to an int*?
>>
>> Because it would drop information and f.e. you won't be able to
>> access the int-arrray behind the int *.
>>
>
> I think you misunderstand how that works. The int pointer would not
> count in bytes, but in ints. So if you do ptr++, then it would actually
> increase by 1 - not by 4 or 8 as it does on the usual platforms, where
> there is no difference between int*, char*, void* on the machine code
> level.

Name an architecture of the last three decades that behaves like that.

David Brown

unread,
Sep 1, 2021, 2:20:15 AMSep 1
to
By the definition of "byte", all C and C++ targets are byte addressable.

>
> Lynn
>

There are plenty of them - they are all around you, but you don't notice
them. DSP's are often word addressable, where "word" can be anything
from 12 to perhaps 36 bits, with a range of values in between. And
there are very good reasons for not making them 8-bit byte addressable.

But it is relatively rare that there are C++ compilers for these
systems, and they have larger CHAR_BIT rather than having different
sized pointers for char* and int*.

Christian Gollwitzer

unread,
Sep 1, 2021, 2:35:14 AMSep 1
to
Am 01.09.21 um 08:03 schrieb Bonita Montero:
You are repeating Alf's original question. Read the whole thread for an
answer.

Christian

Bonita Montero

unread,
Sep 1, 2021, 2:43:29 AMSep 1
to
You have too much phantasy. You're ideas would make the design of a
CPU more complex - without any benefit.

Christian Gollwitzer

unread,
Sep 1, 2021, 2:55:55 AMSep 1
to
Am 01.09.21 um 08:43 schrieb Bonita Montero:
On the contrary. It makes the hardware design simpler. You can address
more memory with a smaller number of bits in the registers. For
non-aligned addresses, you need to load two words and then assemble them
back with shifts etc. Modern Intel-like CPUs do this in hardware, but it
is still slower than aligned access, earlier machines simply had no way
to do this.

The whole concept is called "word addressing" and used to be a thing in
early architectures, because it is simpler to build a 64bit CPU that can
only load aligned addresses.

https://en.wikipedia.org/wiki/Word_addressing#Examples

David Brown mentions DSPs above and I can imagine that many modern GPUs
also use word addressing - though the details of these architectures are
not documented and hidden in the CL compilers inside the graphics drivers.

Christian

David Brown

unread,
Sep 1, 2021, 3:27:14 AMSep 1
to
It must be nice to have such a solid confidence in being sure of
everything you say, despite such limited knowledge. With your
fortune-telling abilities and unwavering surety in your predictions, I
think you are wasted in the programming world. Perhaps a career in
politics would be better? Or start your own religion? Maybe you should
try your luck as a professional lottery winner.


Meanwhile, back in the real world, processors have been, are, and will
be more diverse than your little imagination can fathom. /You/ might
not ever write code for them, but they exist nonetheless.

Bo Persson

unread,
Sep 1, 2021, 3:57:31 AMSep 1
to
Right, malloc(sizeof(int)) is required to return memory properly aligned
for objects of that size. The standard exlicitly says so.

Even on current byte addressed machines, malloc(1) gets us 8- or
16-bytes aligned allocations, partly to reduce memory fragmentation.

Bo Persson

unread,
Sep 1, 2021, 4:06:12 AMSep 1
to
The 8088 in the original IBM PC had an 8-bit external data bus, so
always loaded one byte at a time. Intel's designs are still cursed by this.



Bonita Montero

unread,
Sep 1, 2021, 4:10:36 AMSep 1
to
Am 01.09.2021 um 08:55 schrieb Christian Gollwitzer:

> On the contrary. It makes the hardware design simpler. You can address
> more memory with a smaller number of bits in the registers.

Having the same registers with different types of differnt sets of
registers with different types makes them more complex.

Bonita Montero

unread,
Sep 1, 2021, 4:13:28 AMSep 1
to
Am 01.09.2021 um 09:57 schrieb Bo Persson:

> Even on current byte addressed machines, malloc(1) gets us 8- or
> 16-bytes aligned allocations, partly to reduce memory fragmentation.

No, just to limit the number of size-pools.
With modern allocators like jemallic, mimalloc or tcmalloc, fragmen-
tation isn't an issue for the small size pools and on 64 bit machines
isn't an issue for medium size pools (large blocks are usually directly
allocated via mmap() e.g.).

Bonita Montero

unread,
Sep 1, 2021, 4:14:42 AMSep 1
to
Am 01.09.2021 um 09:26 schrieb David Brown:
> On 01/09/2021 07:25, Bonita Montero wrote:
>> Am 31.08.2021 um 22:37 schrieb Vir Campestris:
>>> 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.
>>
>> That must be decades ago.
>> And currently and in the future no one designs such silly CPUs.
>
> It must be nice to have such a solid confidence in being sure of
> everything you say, despite such limited knowledge. With your
> fortune-telling abilities and unwavering surety in your predictions,
> I think you are wasted in the programming world. Perhaps a career
> in politics would be better? Or start your own religion? Maybe
> you should try your luck as a professional lottery winner.

Name a current CPU with the discussed properties !
Giv me a link to the CPU-documentation.

Bo Persson

unread,
Sep 1, 2021, 4:28:25 AMSep 1
to
Not designed lately, but still in use.

Unisys offered their Burroughs and Univac mainframes well into the 2010's.


Here is a manual for their 36-bit C-compiler from 2014

https://public.support.unisys.com/2200/docs/cp16.0/pdf/78310422-012.pdf

Bo Persson

unread,
Sep 1, 2021, 4:38:06 AMSep 1
to
The famous example is the Cray supercomputers that had vector registers
with 64x64-bits. You never stored pointers in those.

By using 64-bit words, they could get away with using only 24-bits in
their dedicated address registers. A simplification of that part.


Bonita Montero

unread,
Sep 1, 2021, 4:44:32 AMSep 1
to
Am 01.09.2021 um 10:37 schrieb Bo Persson:
> On 2021-09-01 at 10:10, Bonita Montero wrote:
>> Am 01.09.2021 um 08:55 schrieb Christian Gollwitzer:
>>
>>> On the contrary. It makes the hardware design simpler. You can
>>> address more memory with a smaller number of bits in the registers.
>>
>> Having the same registers with different types of differnt sets of
>> registers with different types makes them more complex.
>
> The famous example is the Cray supercomputers that had vector registers
> with 64x64-bits. You never stored pointers in those.

That's sth. totally different than pointer-typed registers.

Bo Persson

unread,
Sep 1, 2021, 4:45:18 AMSep 1
to
On 2021-09-01 at 10:13, Bonita Montero wrote:
> Am 01.09.2021 um 09:57 schrieb Bo Persson:
>
>> Even on current byte addressed machines, malloc(1) gets us 8- or
>> 16-bytes aligned allocations, partly to reduce memory fragmentation.
>
> No, just to limit the number of size-pools.

And why do they have memory pools? :-)

Note that I said "partly". Another reason is that some pool allocators
use the space of the freed memory block to administer the pool. Then
there is a 1-2 pointer minimum size for a block.

Bo Persson

unread,
Sep 1, 2021, 4:49:11 AMSep 1
to
On 2021-09-01 at 10:44, Bonita Montero wrote:
> Am 01.09.2021 um 10:37 schrieb Bo Persson:
>> On 2021-09-01 at 10:10, Bonita Montero wrote:
>>> Am 01.09.2021 um 08:55 schrieb Christian Gollwitzer:
>>>
>>>> On the contrary. It makes the hardware design simpler. You can
>>>> address more memory with a smaller number of bits in the registers.
>>>
>>> Having the same registers with different types of differnt sets of
>>> registers with different types makes them more complex.
>>
>> The famous example is the Cray supercomputers that had vector
>> registers with 64x64-bits. You never stored pointers in those.
>
> That's sth. totally different than pointer-typed registers.

Yes, but having different sets of registers with different types made
the total design *less* complex.

Bonita Montero

unread,
Sep 1, 2021, 4:51:37 AMSep 1
to
Am 01.09.2021 um 10:48 schrieb Bo Persson:
> On 2021-09-01 at 10:44, Bonita Montero wrote:
>> Am 01.09.2021 um 10:37 schrieb Bo Persson:
>>> On 2021-09-01 at 10:10, Bonita Montero wrote:
>>>> Am 01.09.2021 um 08:55 schrieb Christian Gollwitzer:
>>>>
>>>>> On the contrary. It makes the hardware design simpler. You can
>>>>> address more memory with a smaller number of bits in the registers.
>>>>
>>>> Having the same registers with different types of differnt sets of
>>>> registers with different types makes them more complex.
>>>
>>> The famous example is the Cray supercomputers that had vector
>>> registers with 64x64-bits. You never stored pointers in those.
>>
>> That's sth. totally different than pointer-typed registers.
>
> Yes, but having different sets of registers with different types made
> the total design *less* complex.

And what's when you have a pointer to a structure with differently
typed members ? You'd have to make a special lea with a special
destination-type before you store or fetch the member.
Do you really still believe such pointers would make the design
of a CPU simpler ?
And think further: if you have sth like a MMU, you would have to
translate those pointers back to unified pointers.

Bonita Montero

unread,
Sep 1, 2021, 5:05:36 AMSep 1
to
Am 01.09.2021 um 10:44 schrieb Bo Persson:
> On 2021-09-01 at 10:13, Bonita Montero wrote:
>> Am 01.09.2021 um 09:57 schrieb Bo Persson:
>>
>>> Even on current byte addressed machines, malloc(1) gets us 8- or
>>> 16-bytes aligned allocations, partly to reduce memory fragmentation.
>>
>> No, just to limit the number of size-pools.
>
> And why do they have memory pools?  :-)

To prevent that they would otherwise allocate larger blocks directly
from the kernel, which is slower.

>
> Note that I said "partly". Another reason is that some pool allocators
> use the space of the freed memory block to administer the pool. Then
> there is a 1-2 pointer minimum size for a block.

Modern memory-allocators have zero overhead for small allocated blocks.
They're allocated from a 2^N-aligned pool and if they're deallocated
their pool is found by dropping just some bits of their address. When
they're unallocated there's some overhead - which results in there's
a minimum size inside the pool.

David Brown

unread,
Sep 1, 2021, 5:07:42 AMSep 1
to
I don't really expect you to read this - it would be too out of
character. You'll just snip the reply and give some insult confirming
that your social skills are as poor as your understanding of the wider
world of processors. But others might be interested.


To get you started, here is a 32-bit DSP:

<https://en.wikipedia.org/wiki/Super_Harvard_Architecture_Single-Chip_Computer>

<https://www.analog.com/en/products/audio-video/audio-signal-processors/sharc-audio-processors-socs.html>

There are C and C++ compilers available.

There is no direct access to octets in the architecture - all hardware
accesses to data are in 32-bit words. To my knowledge (and I've only
had very indirect involvement with these particular devices, I haven't
programmed them), the compilers use CHAR_BIT 32 and thus void*, char*
and int* pointers are all the same size. It would certainly be possible
to be more sophisticated, using CHAR_BIT as 8 and providing char*
pointers that have an extra 2 bits for the offset within the word. But
given the target usage of these devices, it is simpler and more
efficient to stick to word pointers. If you want programmer-friendly
character and string handling, make yourself a C++ class to support fat
pointers.

Another microcontroller family with CHAR_BIT 16 that I have used is
<https://en.wikipedia.org/wiki/Texas_Instruments_TMS320>. While the
original 16-bit families are rarely used for serious DSP these days,
they are some of the most popular chips for high reliability and high
temperature applications.


Microcontrollers that can address at least part of their memory at the
single bit level include the immensely popular 8051 and ARM Cortex M
families.


Processors with less usual bit sizes are not as easily referenced - for
many, little information is available except for customers and the
devices are often customised for specific end products. You can do your
own research if you want.

David Brown

unread,
Sep 1, 2021, 5:12:08 AMSep 1
to
Are you a reincarnation of Marie Antoinette? All we hear from you is
"let them eat cake".

You probably won't understand what I mean, which shows why the analogy
fits you.

Bo Persson

unread,
Sep 1, 2021, 5:15:41 AMSep 1
to
On 2021-09-01 at 10:51, Bonita Montero wrote:
> Am 01.09.2021 um 10:48 schrieb Bo Persson:
>> On 2021-09-01 at 10:44, Bonita Montero wrote:
>>> Am 01.09.2021 um 10:37 schrieb Bo Persson:
>>>> On 2021-09-01 at 10:10, Bonita Montero wrote:
>>>>> Am 01.09.2021 um 08:55 schrieb Christian Gollwitzer:
>>>>>
>>>>>> On the contrary. It makes the hardware design simpler. You can
>>>>>> address more memory with a smaller number of bits in the registers.
>>>>>
>>>>> Having the same registers with different types of differnt sets of
>>>>> registers with different types makes them more complex.
>>>>
>>>> The famous example is the Cray supercomputers that had vector
>>>> registers with 64x64-bits. You never stored pointers in those.
>>>
>>> That's sth. totally different than pointer-typed registers.
>>
>> Yes, but having different sets of registers with different types made
>> the total design *less* complex.
>
> And what's when you have a pointer to a structure with differently
> typed members ? You'd have to make a special lea with a special
> destination-type before you store or fetch the member.
> Do you really still believe such pointers would make the design
> of a CPU simpler ?

No. The Cray only got 64-bit words from memory (or 64x64-bits for vector
computations).

Sure, text processing would be a bit hard, but that wasn't a concern for
the Cray design.


> And think further: if you have sth like a MMU, you would have to
> translate those pointers back to unified pointers.

No, the word addresses *are* what the memory hardware is using. There
are no rules that 64-bit data must have a 64-bit address.

Even the current x86-64 doesn't care to send all 64-bits on the address bus.

Bo Persson

unread,
Sep 1, 2021, 5:18:05 AMSep 1
to
On 2021-09-01 at 11:05, Bonita Montero wrote:
> Am 01.09.2021 um 10:44 schrieb Bo Persson:
>> On 2021-09-01 at 10:13, Bonita Montero wrote:
>>> Am 01.09.2021 um 09:57 schrieb Bo Persson:
>>>
>>>> Even on current byte addressed machines, malloc(1) gets us 8- or
>>>> 16-bytes aligned allocations, partly to reduce memory fragmentation.
>>>
>>> No, just to limit the number of size-pools.
>>
>> And why do they have memory pools?  :-)
>
> To prevent that they would otherwise allocate larger blocks directly
> from the kernel, which is slower.
>

So it's not that limiting allocations to just some sizes reduces memory
fragmentation?


Bonita Montero

unread,
Sep 1, 2021, 6:15:55 AMSep 1
to
Am 01.09.2021 um 11:15 schrieb Bo Persson:
> On 2021-09-01 at 10:51, Bonita Montero wrote:
>> Am 01.09.2021 um 10:48 schrieb Bo Persson:
>>> On 2021-09-01 at 10:44, Bonita Montero wrote:
>>>> Am 01.09.2021 um 10:37 schrieb Bo Persson:
>>>>> On 2021-09-01 at 10:10, Bonita Montero wrote:
>>>>>> Am 01.09.2021 um 08:55 schrieb Christian Gollwitzer:
>>>>>>
>>>>>>> On the contrary. It makes the hardware design simpler. You can
>>>>>>> address more memory with a smaller number of bits in the registers.
>>>>>>
>>>>>> Having the same registers with different types of differnt sets of
>>>>>> registers with different types makes them more complex.
>>>>>
>>>>> The famous example is the Cray supercomputers that had vector
>>>>> registers with 64x64-bits. You never stored pointers in those.
>>>>
>>>> That's sth. totally different than pointer-typed registers.
>>>
>>> Yes, but having different sets of registers with different types made
>>> the total design *less* complex.
>>
>> And what's when you have a pointer to a structure with differently
>> typed members ? You'd have to make a special lea with a special
>> destination-type before you store or fetch the member.
>> Do you really still believe such pointers would make the design
>> of a CPU simpler ?
>
> No. The Cray only got 64-bit words from memory (or 64x64-bits for vector
> computations).

That's sth. different than what we've been discussing: typed pointers.

> No, the word addresses *are* what the memory hardware is using.

They would have a typeing or not; in one case you would revert it,
in the other case you would have to make the MMU also typed; both
would be a mess.

Bonita Montero

unread,
Sep 1, 2021, 6:18:14 AMSep 1
to
The discussion is about if there's fragmentation among different
allocations, i.e. external fragmentation, with modern alllocations.
Most allocations are small sized allocations, and with modern allo-
cators theres no external fragmentation at all for this size class
since the allocations are rounded up to 2^N (f.e. with mimalloc up
to 8kB) and looked up in a pool which is also 2^N - the result is
no fragementation among the allocations.

Bonita Montero

unread,
Sep 1, 2021, 6:19:16 AMSep 1
to
Study the architecture of mimalloc, jemalloc or tcmalloc before you
make nonsense-statements.

Bo Persson

unread,
Sep 1, 2021, 6:49:01 AMSep 1
to
Or, like someone said earlier:

Bonita Montero

unread,
Sep 1, 2021, 6:55:08 AMSep 1
to
Fragmentation is usually considered as fragmentation among the
allocations and not internal fragmentation.

james...@alumni.caltech.edu

unread,
Sep 1, 2021, 9:49:11 AMSep 1
to
They don't have different types of registers. Such architectures have only one
set of word-addressed registers - byte access is implemented by loading a word
and then using bit-wise operators to access the bits that correspond to a
particular byte. For precisely that reason, such architectures are not normally
used in ways that require that a lot of byte-addressed accesses.

Bonita Montero

unread,
Sep 1, 2021, 9:50:18 AMSep 1
to
Am 01.09.2021 um 15:49 schrieb james...@alumni.caltech.edu:
> On Wednesday, September 1, 2021 at 4:10:36 AM UTC-4, Bonita Montero wrote:
>> Am 01.09.2021 um 08:55 schrieb Christian Gollwitzer:
>>
>>> On the contrary. It makes the hardware design simpler. You can address
>>> more memory with a smaller number of bits in the registers.
>> Having the same registers with different types of differnt sets of
>> registers with different types makes them more complex.
>
> They don't have different types of registers. Such architectures have only one
> set of word-addressed registers - ...

The above is not about the width of access ...

james...@alumni.caltech.edu

unread,
Sep 1, 2021, 10:16:44 AMSep 1
to
I'm not sure what your point is. To make my point clearer, consider a concrete
though hypothetical example, with a small memory size because such an
implementation is more plausible on such a platform. It's a 16-bit processor that
can only have 65536 words of memory attached. It is word-addressed, so a single
16-bit word is sufficient to address every single word of memory. An implementor
chooses to make CHAR_BIT==8, because what little text processing is done by this
processor is usually done on 8-bit characters. Reading a single byte is emulated by
reading a single word and using bit-wise operators to extract the appropriate byte
from that word. Writing a single byte is emulated by reading in a single word, using
the bit-wise operators to update only those bits that correspond to the target byte,
and then writing that entire word to the output. It will frequently be possible to
optimize operations that nominally involve reading or writing large numbers of bytes
by re-writing them to use word accesses. The [[un]signed] char* and void* types are
byte-addressed pointer types implemented by storing a one-bit byte offset along
with the the word address, taking up at least 3 bytes. 4 byte pointers would be
faster but would take up a lot more space. Pointers to all other types, which are
word aligned, are only 2 bytes, containing only the word address. The typical
applications for this platform won't be storing large numbers of byte-addressed
pointers.
On such a platform, forcing sizeof(int*) == sizeof(void*) would require that all
pointers contain at least 3 bytes, even pointers to word-aligned types for which one
of those bytes would be guaranteed to contain a byte offset of 0. Don't you
understand how inefficient that would be?
Note: while modern CPUs are getting bigger and bigger, tiny CPUs are also being
produced in large quantities, and C cross-compilers are being built for such CPUs.