Date: Thu, 9 May 2024 11:23:57 +0100
On Thu, 9 May 2024 at 11:01, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I reply to Jonathan, Sebastian and Tiago in series below.
>
>
> On Thu, May 9, 2024 at 10:16 AM Jonathan Wakely wrote:
> >
> > As usual, you haven't provided a reason why doing that
> > would be useful. All you've said is it might be possible.
>
>
> Use Case 1:
>
> Early this year I shared a paper on "std::unaligned":
>
> http://www.virjacode.com/papers/unaligned_latest.pdf
>
> When I was writing the class "std::unaligned", I was considering
> storing the address of an unaligned T inside a T*. I'll give a
> hypothetical architecture:
> T = int
> CHAR_BIT == 16
> sizeof(int) == 2
> UINT_MAX == 4294967295
>
> So int's are 32-Bit, and the smallest addressable unit of memory is 16
> bits. So if you have an array of three int's, the respective addresses
> of the 3 ints are:
> 0x2000
> 0x2002
> 0x2004
>
> The memory address 0x2001 would be an int unaligned by 16 bits, but
> there's no way of specifying an int unaligned by 8 bits.
Just like you cannot specify the address of an int misaligned by 4 bits, on
any platform. Why is that a problem?
If you need to solve it for this hypothetical architecture, why don't we
also need to allow misaligning by 4 bits on architectures like x86?
> Therefore
> this platform can be described as follows:
> (1) sizeof(char*) > sizeof(int*)
>
Why would that be true?
CHAR_BIT == 16 which means every char has 16 bits and so is aligned to a
16-bit boundary as well. That's what CHAR_BIT means, by definition.
> (2) You cannot store the address of an unaligned T inside a T*
>
> However . . . in the future . . . if C++26 were to mandate that all
> data pointers are intercompatible, then we could store the address of
> an unaligned T inside a T*.
>
Only if it's misaligned by 8 bits. What about being misaligned by 4 bits?
Or 7? What is the problem you're solving?
std-proposals_at_[hidden]> wrote:
> I reply to Jonathan, Sebastian and Tiago in series below.
>
>
> On Thu, May 9, 2024 at 10:16 AM Jonathan Wakely wrote:
> >
> > As usual, you haven't provided a reason why doing that
> > would be useful. All you've said is it might be possible.
>
>
> Use Case 1:
>
> Early this year I shared a paper on "std::unaligned":
>
> http://www.virjacode.com/papers/unaligned_latest.pdf
>
> When I was writing the class "std::unaligned", I was considering
> storing the address of an unaligned T inside a T*. I'll give a
> hypothetical architecture:
> T = int
> CHAR_BIT == 16
> sizeof(int) == 2
> UINT_MAX == 4294967295
>
> So int's are 32-Bit, and the smallest addressable unit of memory is 16
> bits. So if you have an array of three int's, the respective addresses
> of the 3 ints are:
> 0x2000
> 0x2002
> 0x2004
>
> The memory address 0x2001 would be an int unaligned by 16 bits, but
> there's no way of specifying an int unaligned by 8 bits.
Just like you cannot specify the address of an int misaligned by 4 bits, on
any platform. Why is that a problem?
If you need to solve it for this hypothetical architecture, why don't we
also need to allow misaligning by 4 bits on architectures like x86?
> Therefore
> this platform can be described as follows:
> (1) sizeof(char*) > sizeof(int*)
>
Why would that be true?
CHAR_BIT == 16 which means every char has 16 bits and so is aligned to a
16-bit boundary as well. That's what CHAR_BIT means, by definition.
> (2) You cannot store the address of an unaligned T inside a T*
>
> However . . . in the future . . . if C++26 were to mandate that all
> data pointers are intercompatible, then we could store the address of
> an unaligned T inside a T*.
>
Only if it's misaligned by 8 bits. What about being misaligned by 4 bits?
Or 7? What is the problem you're solving?
Received on 2024-05-09 10:25:17