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

[Alf P. Steinbach]

Are there any examples of current platforms/architectures where
sizeof(void*) > sizeof(int*) ?

- Alf

[Lynn McGuire]

Are there any old platforms where this was the case also ?

Lynn

[Siri Cruise]

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]

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]

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]

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]

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]

I have never heard of C++ (conforming to any of standards) implemented
(or ported) for any of those.

[Bonita Montero]

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]

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]

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]

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]

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]

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]

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]

Probability is 100%. See Unisys Clearpath C compiler reference
manual.

[Bonita Montero]

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]

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]

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]

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]

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]

As someone whose day job is designing CPUs, I find your naivete
amusing.

[Bonita Montero]

There is no person designing such CPUs today and there will never be.

[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.
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]

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]

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]

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]

Why not? If void* is larger than int*, why couldn't you cast a
void* to an int*?

[Lynn McGuire]

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]

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]

Because it would drop information and f.e. you won't be able to
access the int-arrray behind the int *.

[Christian Gollwitzer]

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]

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]

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]

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]

You have too much phantasy. You're ideas would make the design of a
CPU more complex - without any benefit.

[Christian Gollwitzer]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Study the architecture of mimalloc, jemalloc or tcmalloc before you
make nonsense-statements.

[Bo Persson]

Or, like someone said earlier:

[Bonita Montero]

Fragmentation is usually considered as fragmentation among the
allocations and not internal fragmentation.

[james...@alumni.caltech.edu]

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]

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]

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.

[Bonita Montero]

Am 01.09.2021 um 16:16 schrieb james...@alumni.caltech.edu:
> On Wednesday, September 1, 2021 at 9:50:18 AM UTC-4, Bonita Montero wrote:
>> 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 ...
>
> 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. ...

We're discussing typed pointers and not different memory-access
capabilities regarding different widths.

[James Kuyper]

On 9/1/21 5:07 AM, David Brown wrote:
...

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

It would be more relevant if you could have identified an implementation
that actually does that, rather then merely saying that such an
implementation is possible.

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

CHAR_BIT==16 isn't the directly relevant issue. Are there C++
implementations targeting that platform with sizeof(void*) > sizeof(int*)?

[red floyd]

On 8/31/2021 1:37 PM, Vir Campestris wrote:
> 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.

TI-340x0 series? I worked with that one as well.

[Scott Lurndal]

Vir Campestris <vir.cam...@invalid.invalid> writes:
>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.

Andy, you have been successfully trolled.

Our german friend is rather clueless about the industry.

[Scott Lurndal]

Did you not read the link to the Unisys Clearpath C compiler manual? The
computers are still being built and still being used in the
real world.

48-bit words. Pointers are not interchangable.

[Scott Lurndal]

Lynn McGuire <lynnmc...@gmail.com> writes:
>On 8/31/2021 2:01 AM, Bo Persson wrote:
>> On 2021-08-31 at 04:59, 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 ?
>>>
>>> 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.
>
>Yeah, can't think of a reason why to build anything other than a byte
>addressable machine.

Strong words from a fortran programmer. How many CPUs have you
designed in the last forty years?

As David points out, many DSPs are not byte addressable, and there
are other machines _STILL IN DAILY PRODUCTION_ that don't have
byte addressability, yet support C compilers (e.g. both flavors
of Unisys Clearpath).

A modern DPU:

https://www.anandtech.com/show/16790/marvell-announces-octeon-10-dpu-family-first-to-5nm-with-n2-cpus

[red floyd]

Remember the "All-the-world's a vax" heresy?
(https://www.lysator.liu.se/c/ten-commandments.html)?

Ms. Montero seems to be in the All the world's Windows sect.

[Bart]

Why not? Everyone else seems to assume that the whole world is running
some Unix-based system.

Try building GMP on pure Windows (no CYGWIN, MSYS2 or WSL to make it
emulate Linux). GMP is a numerical library; how does the OS come into it?

[Bonita Montero]

Am 01.09.2021 um 17:32 schrieb Scott Lurndal:
> Lynn McGuire <lynnmc...@gmail.com> writes:
>> On 8/31/2021 2:01 AM, Bo Persson wrote:
>>> On 2021-08-31 at 04:59, 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 ?
>>>>
>>>> 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.
>>
>> Yeah, can't think of a reason why to build anything other than a byte
>> addressable machine.
>
> Strong words from a fortran programmer. How many CPUs have you
> designed in the last forty years?
>
> As David points out, many DSPs are not byte addressable, and there
> are other machines _STILL IN DAILY PRODUCTION_ that don't have
> byte addressability, yet support C compilers (e.g. both flavors
> of Unisys Clearpath).

These are not "many" but according to the examples given yet
a homeopathic part.

[David Brown]

I believe there are more dedicated DSP's produced per year than 64-bit
cpus. There may even be more 4-bit microcontrollers still produced than
64-bit cpus. AMD and Intel each sell perhaps 500,000 processors a year
(according to a quick google search). There are DSPs and other
specialist microcontrollers with minimum order quantities of millions.
I know of microcontrollers (programmable in C, and in this case with
8-bit char) that cost $0.03 each.

I don't know what you mean by "not many". In terms of numbers of units,
8-bit devices and "hidden" microcontrollers and DSPs outsell 32-bit
devices by orders of magnitude - and 32-bit devices similarly outsell PC
processors. In terms of numbers of designs or chips available, it's the
same story. PC processors lead in terms of total cost, and lead hugely
in terms of the number of different people programming on them.

[Lynn McGuire]

On 9/1/2021 5:30 AM, Mark Bluemel wrote:

> On Tuesday, 31 August 2021 at 04:00:06 UTC+1, 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 ?
>

> Historically Prime (aka Pr1me) 50-series machines had this.
>
> The underlying architecture was based on 16-bit "half-words", with the memory organized into segments.
>
> As I recall, the standard 32-pointer held a 2-bit protection/privilege ring number, 14-bits of segment number and 16-bits of offset to a half-word in the segment.
> Accessing 8-bit bytes was via a 48-bit pointer with the final 16-bits dedicated to holding 0 or 1 as the offset of the byte in the half-word (honestly).
>
> In addition, 8-bit ASCII had the sign bit on rather than off, and native I/O was half-word oriented.
>
> Porting C to it was, I gather, a bit of a pain. Oh - and when you incremented a pointer past the end of a segment, it would wrap back to the beginning of that segment, not move on to the next, if I recall correctly.
>
> For a later C release, an alternative form of 32-bit addressing was added - I can't remember the details, but think the ring number bits were repurposed.

Good night, what a mess !

We had a Prime model 450 in 1977 and a model 750 in 1980 ???. And then
a model 2xxx ??? in 1985 ??? The only compilers they had that I knew of
were the Fortran, Cobol, and PL/I ???

Lynn

[Scott Lurndal]

Ask the developers of GMP. It was their choice. Given the 'G'
in the name, one could expect that they had no interest in supporting
Windows.

[Juha Nieminen]

Bo Persson <b...@bo-persson.se> wrote:
> Even on current byte addressed machines, malloc(1) gets us 8- or
> 16-bytes aligned allocations, partly to reduce memory fragmentation.

I think that's a practical necessity due to the bookkeeping data
that the clib allocator needs with each allocated block, which
ostensibly has some register-sized counters and/or memory
addresses, which are most efficient when aligned to their size.

Thus, I wouldn't be surprised if malloc() (and new) always returns
a block that's aligned at a very minimum to the size of a pointer.

[Lynn McGuire]

Your numbers for AMD and Intel are WAY off. There were 275 million PCs
sold in 2020 containing Intel or AMD cpus.

https://www.statista.com/statistics/273495/global-shipments-of-personal-computers-since-2006/

Lynn

[David Brown]

On 01/09/2021 16:31, James Kuyper wrote:
> On 9/1/21 5:07 AM, David Brown wrote:
> ...
>> 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.
>
> It would be more relevant if you could have identified an implementation
> that actually does that, rather then merely saying that such an
> implementation is possible.
>

It would, and I'd have said if I knew of such an implementation.

>
>> 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.
>
> CHAR_BIT==16 isn't the directly relevant issue. Are there C++
> implementations targeting that platform with sizeof(void*) > sizeof(int*)?
>

I don't know of any, nor have I said I did. The thread has strayed as
Bonita has denied the existence of pretty much any processor that
doesn't follow her very limited idea of what what she thinks a modern
processor is. I have just been showing some real-life counter examples,
even though they are not as extreme as the OP was hoping for.

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> Ask the developers of GMP. It was their choice. Given the 'G'
> in the name, one could expect that they had no interest in supporting
> Windows.

GMP is intended to be a serious extremely efficient multi-precision
arithmetic library aimed at all kinds of work, including things like
serious scientific numeric analysis, and it's being used by a lot
of software out there.

It would be rather insane to exclude one of the most popular (if
not the most popular) operating systems because of some silly
principle.

[David Brown]

They did look odd when I read them - perhaps the statistics page I found
was referring to a limited type of chip. Anyway, small devices still
massively outsell them in numbers.

[Bonita Montero]

Am 01.09.2021 um 20:14 schrieb Juha Nieminen:

> Thus, I wouldn't be surprised if malloc() (and new) always returns
> a block that's aligned at a very minimum to the size of a pointer.

malloc() returns a pointer which is aligned at least to max_align_t:
https://en.cppreference.com/w/c/types/max_align_t

[Bonita Montero]

Am 01.09.2021 um 19:44 schrieb David Brown:

> I believe there are more dedicated DSP's produced per year than 64-bit
> cpus. There may even be more 4-bit microcontrollers still produced than
> 64-bit cpus. AMD and Intel each sell perhaps 500,000 processors a year
> (according to a quick google search). There are DSPs and other
> specialist microcontrollers with minimum order quantities of millions.
> I know of microcontrollers (programmable in C, and in this case with
> 8-bit char) that cost $0.03 each.

The issue is not about whether they're can't address raw bytes but just
larger quantities. The issue is about machines with typed pointers, i.e.
when you cast a pointer they change their bit-representation, and these
exist in a homeopathic amount.

[Scott Lurndal]

300 million X86 (intel, amd) processors per year, including servers.
6 billion arm processors per _quarter_.
1.5 billion ARC processors per year.
400 million MIPS processors per year.

[Scott Lurndal]

If they were in it for profit, perhaps. But it's more likely they
find open-source as a philosophy inconsistent with active support for
proprietary closed operating environments.

[Scott Lurndal]

In fact it is required by both C and POSIX standards to return an
address aligned to the largest valid machine type (16 bytes, in most
modern cases).

[Bonita Montero]

And if you don't have a modern thread-pooling allocator you get a
lot of false shares.

[Christian Gollwitzer]

Am 01.09.21 um 21:02 schrieb Scott Lurndal:

And, even more likely, there is no volunteer available to maintain a
Windows-only alternative Makefile / build solution. They write on their
page "GMP's main target platforms are Unix-type systems, such as
GNU/Linux, Solaris, HP-UX, Mac OS X/Darwin, BSD, AIX, etc. It also is
known to work on Windows in both 32-bit and 64-bit mode."

So you *can* run it on Windows. MSYS2, btw, is not some sort of Linux
emulation for Windows, as it might seem and opposed to Cygwin or WSL. If
you compile software using MSYS2, you use the tools for building,
therefore you can use GNU make, bash , autoconf etc. but the resulting
binary is a true Windows binary. autoconf even knows how to use the cl
compiler (MSVC++) instead of gcc. I haven't tried GMP, though.

Usual developers don't find it particularly exciting to write build
scripts, but if you'd volunteer to write and maintain good Windows
Makefiles, probably they would accept a pull request.

Christian

[Bo Persson]

Not entirely correct. The allocated storage must be properly aligned for
an object of that size.

So if smaller than a long double, it can also be less aligned.

[Lynn McGuire]

Yup, not surprised. What is your source ?

Lynn

[Scott Lurndal]

Industry analyst documents that I'm not free to share.

But if you look at Toms Hardware you may find similar numbers.

[James Kuyper]

On 9/1/21 3:03 PM, Scott Lurndal wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
...

>> I think that's a practical necessity due to the bookkeeping data
>> that the clib allocator needs with each allocated block, which
>> ostensibly has some register-sized counters and/or memory
>> addresses, which are most efficient when aligned to their size.
>>
>> Thus, I wouldn't be surprised if malloc() (and new) always returns
>> a block that's aligned at a very minimum to the size of a pointer.
>
> In fact it is required by both C and POSIX standards to return an
> address aligned to the largest valid machine type (16 bytes, in most
> modern cases).

malloc() is required to return an address suitably aligned for the most
strictly aligned type. However, the most strictly aligned type needn't
be the largest machine type, and the alignment requirement for that type
could be smaller than the size of the type.

The size of a given pointer type must be an integer multiple of the
alignment requirement for that type. The maximum alignment requirement
must, in particular, be no smaller than the alignment requirement for
any particular pointer type. Other than those two facts, there's no
guaranteed relationship between the strictest alignment requirement and
the size of any particular pointer type.

[Vir Campestris]

On 01/09/2021 09:05, Bo Persson wrote:
> 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.

And that of course inherits features from the 8080.

I've never used a 4004, but I won't be surprised to find some of the
features originated there.

Andy

[Vir Campestris]

On 01/09/2021 16:21, Scott Lurndal wrote:
> Vir Campestris <vir.cam...@invalid.invalid> writes:
>> 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.
>
> Andy, you have been successfully trolled. >
> Our german friend is rather clueless about the industry.
>

Even before I got to this I was considering a filter - but some of the
replies in this thread have been quite interesting.

Andy

[David Brown]

They don't exclude any platform. It's simply that the people behind GMP
do serious scientific and mathematical work, and like most people who do
such work, they use *nix. So that is their main platform for
development work. Due to the variety of *nix systems, it means their
code will be quite portable to different processors. However, it is
also likely to be strongly geared towards gcc and compatible compilers
(clang, icc). And it is distributed like many *nix libraries and tools
- you get the source, and compile it for the system you want to use in
the way you want to use it, optimised as best you can for exactly the
system you are running on. They don't bother with the Windows tradition
of pre-built binaries targeting the lowest common denominator of all
Windows-compatible processors.

If you can work a POSIX-like environment on Windows - mingw, Cygwin,
etc., - then you can download and compile GMP. If you can't get such an
environment to work correctly, you are unlikely to be able to make much
use of a library like GMP anyway.

Most GNU developers don't explicitly exclude Windows - they simply don't
go out of their way to spoon-feed Windows users.

[Chris M. Thomasson]

On 9/1/2021 2:17 AM, Bo Persson wrote:
> 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?
>
>

A long time ago, I created some memory allocators that would round the
size up to a pointer. So, if a pointer was the size of 32 bits, and the
request size was say, 2 bytes, it would be rounded up to 32 bits. When
we want to free the block, its address was *rounded down to get at the
header, then the block was inserted in a lifo linked list.

*The header would be aligned on a large boundary.

So, any pointer in the header can be rounded down to get back to the header.

[Bart]

There are other ways of doing that, some of which I used to use. For
example you can supply a one-file source-code amalgamation of your
product (I used C), one step back from the usual one-file executable binary.

This is then trivial to build with minimum dependencies (a compiler,
which /can/ be as simple as you like; the requirements are different
from development).

> If you can work a POSIX-like environment on Windows - mingw, Cygwin,
> etc., - then you can download and compile GMP. If you can't get such an
> environment to work correctly, you are unlikely to be able to make much
> use of a library like GMP anyway.
>
> Most GNU developers don't explicitly exclude Windows - they simply don't
> go out of their way to spoon-feed Windows users.
>

They don't go out of their to remove the numerous OS-specific
dependencies their development relies on. And this was my point - they
assume the whole world runs on Unix [or Unix derivatives etc].

So in the case of GMP, the first step is to run an insanely complex
30,500-line configure script that will is never going to work on
anything other than Linux or compatible system.

[Keith Thompson]

That's not what the 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).

It can be difficult to tell whether
double *p = malloc(1);
gives you proper alignment, but the standard doesn't give permission for
small allocations to have less strict alignment.

(BTW, there's no guarantee that long double has the strictest alignment.)

--
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 */

[Bonita Montero]

Am 01.09.2021 um 21:55 schrieb Bo Persson:
> On 2021-09-01 at 20:34, Bonita Montero wrote:
>> Am 01.09.2021 um 20:14 schrieb Juha Nieminen:
>>
>>> Thus, I wouldn't be surprised if malloc() (and new) always returns
>>> a block that's aligned at a very minimum to the size of a pointer.
>>
>> malloc() returns a pointer which is aligned at least to max_align_t:
>> https://en.cppreference.com/w/c/types/max_align_t
>
> Not entirely correct. The allocated storage must be properly aligned for
> an object of that size.

No, it's like what I said:

> So if smaller than a long double, it can also be less aligned.

No.

[Juha Nieminen]

Christian Gollwitzer <auri...@gmx.de> wrote:
> And, even more likely, there is no volunteer available to maintain a
> Windows-only alternative Makefile / build solution. They write on their
> page "GMP's main target platforms are Unix-type systems, such as
> GNU/Linux, Solaris, HP-UX, Mac OS X/Darwin, BSD, AIX, etc. It also is
> known to work on Windows in both 32-bit and 64-bit mode."
>
> So you *can* run it on Windows. MSYS2, btw, is not some sort of Linux
> emulation for Windows, as it might seem and opposed to Cygwin or WSL.

You can run *what* on Windows? GMP is not a program. It's a library,
which you can use in your programs.

It's just a question of how many hurdles the developers have put to
make it possible to compile it so that you can use it in your program.

(One thing I really detest in the unix style source code design is the
ubiquitous all-encompassing configure script, which is quite often used
even in projects that wouldn't need one. Essentially, the library is,
for all intents and purposes, being "held hostage" by its configure script.
It won't compile as-is unless you run the configure script first, and the
script will only run on a unix environment, and generally will only be
able to configure the library to be compiled for the current host operating
system. Depending on the complexity of the project, trying to compile it
without running the script may be almost insurmountable, as it would require
manually defining millions of things, manually creating very large files,
and so on.

This is not only detrimental to trying to compile the project for a non-unix
platform (even if the source code of the project could well be 100% portable
without any need for this), but it also makes it extraordinarily difficult
to cross-compile it to another platform than the current one. Such as
trying to use such a library in an iOS project. I know. I have pulled my
hair many times because of this. It has taught me to *hate* unix-style
configure scripts, and them keeping completely portable libraries as
hostages.)

[Paavo Helde]

01.09.2021 20:11 Bart kirjutas:
>
> Try building GMP on pure Windows (no CYGWIN, MSYS2 or WSL to make it
> emulate Linux). GMP is a numerical library; how does the OS come into it?

With such libraries, I have had some success by adding their source
files directly into my project and just ignoring their original build
system.

[David Brown]

On 02/09/2021 08:58, Juha Nieminen wrote:
> Christian Gollwitzer <auri...@gmx.de> wrote:
>> And, even more likely, there is no volunteer available to maintain a
>> Windows-only alternative Makefile / build solution. They write on their
>> page "GMP's main target platforms are Unix-type systems, such as
>> GNU/Linux, Solaris, HP-UX, Mac OS X/Darwin, BSD, AIX, etc. It also is
>> known to work on Windows in both 32-bit and 64-bit mode."
>>
>> So you *can* run it on Windows. MSYS2, btw, is not some sort of Linux
>> emulation for Windows, as it might seem and opposed to Cygwin or WSL.
>
> You can run *what* on Windows? GMP is not a program. It's a library,
> which you can use in your programs.
>
> It's just a question of how many hurdles the developers have put to
> make it possible to compile it so that you can use it in your program.
>
> (One thing I really detest in the unix style source code design is the

<snip>
> hostages.)
>

I doubt if anyone will try to suggest that configure scripts are always
written perfectly, or that even that it is a good way to handle
cross-system compatibility in modern times.

However, you are writing as though the GMP authors have a duty and a
responsibility to make life easier for any programmers, on any system,
with any preferences for how they want to get the library and make use
of it. They have no such duty. These are people who have got together
with a common need - for high-performance arbitrary precision arithmetic
- and decided they would get better results working together on a common
library than doing so separately. I'm sure they also enjoy helping
others, and feel it is a good thing to make their code available.

They don't /owe/ you anything. They don't owe Windows developers
anything. They don't owe Linux developers, or Solaris developers, or
anyone else.

If other people want to make GMP easier to install on Windows, that's
great. If other people want to make it easer to install on Linux, or
anything else, that's great too. Only a small fraction of Linux users
would install it by downloading and doing the ".configure && make &&
make install" dance. Most would do "apt-get install libgmp-dev", or
similar.)

And it turns out that people /have/ made things easier for getting GMP
on Windows. If you use cygwin, the library is there. If you use msys2,
the library is there. If you want to use it from MSVC, instructions and
project settings are available. If you want to use it from Python, or
PHP, or another language, packages are available.

Perhaps things won't work immediately, or there are complications that
you need to work through. But frankly, if you are not able to figure it
out then you are probably not in a position to make much use of such a
library anyway.


One thing we can be sure about, however. If someone provides a library
like this "in the unix way", it might be difficult to use on a Windows
system, but it will be possible (baring unix-specific features). If
they were to make a Windows library in "the Windows way", it can't be
used on anything else. Hell, it probably won't even be usable if you
don't have MSVC, which in turn tries to push you to the latest updates
of the latest version of Windows.