Date: Thu, 4 Sep 2025 08:15:29 +0200
> I have just explained that due to the alignment requirements it can't.
Your explanation is clearly wrong. You absolutely can return
_BitInt(384) from a function. Values (i.e. prvalues) returned from
functions are not objects anyway, so alignment doesn't really apply to
them. The calling conventions could be that this _BitInt(384) result
of the function is stored in some specialized register, similar to how
int return values are stored in eax.
In essence, both from a language perspective and hardware perspective,
alignment requirements are totally irrelevant as to whether it's
technically possible to return something from a function.
I assume your explanation refers to this:
> Let's focus on sha registers.
> What is the alignment of this variable?
> _BitInt(384) shaBuffer; //< This one
> If statement number 2 is true, the answer is 8Bytes, then the statement 1 is wrong.
> You can't use _BitInt(384) to represent that specialized register because it needs an alignment of 64Bytes.
I assume you mean 8 bits and 64 bits, not bytes.
Everything inside a register is perfectly aligned from a hardware
perspective, or rather, alignment doesn't apply to registers.
Alignment is a property of objects, i.e. things in memory. Some
architectures (e.g. x86_64) even let you load misaligned objects into
registers. You can represent the value of a specialized register as a
value of type _BitInt(384) no matter what the alignment of that type
is.
> If the answer is 64Bytes then not only statement 2 is false, it is also incompatible with C.
> Does it have an alignment of 8Bytes or 64Bytes? It can't be both!
Yes, it can't be both. It's simply an implementation-defined choice
made by the platform ABI. The C ABI can make the alignment 8 bits or
64 bits or whatever and C++ can mirror that. Nothing is C-incompatible
here.
Your explanation is clearly wrong. You absolutely can return
_BitInt(384) from a function. Values (i.e. prvalues) returned from
functions are not objects anyway, so alignment doesn't really apply to
them. The calling conventions could be that this _BitInt(384) result
of the function is stored in some specialized register, similar to how
int return values are stored in eax.
In essence, both from a language perspective and hardware perspective,
alignment requirements are totally irrelevant as to whether it's
technically possible to return something from a function.
I assume your explanation refers to this:
> Let's focus on sha registers.
> What is the alignment of this variable?
> _BitInt(384) shaBuffer; //< This one
> If statement number 2 is true, the answer is 8Bytes, then the statement 1 is wrong.
> You can't use _BitInt(384) to represent that specialized register because it needs an alignment of 64Bytes.
I assume you mean 8 bits and 64 bits, not bytes.
Everything inside a register is perfectly aligned from a hardware
perspective, or rather, alignment doesn't apply to registers.
Alignment is a property of objects, i.e. things in memory. Some
architectures (e.g. x86_64) even let you load misaligned objects into
registers. You can represent the value of a specialized register as a
value of type _BitInt(384) no matter what the alignment of that type
is.
> If the answer is 64Bytes then not only statement 2 is false, it is also incompatible with C.
> Does it have an alignment of 8Bytes or 64Bytes? It can't be both!
Yes, it can't be both. It's simply an implementation-defined choice
made by the platform ABI. The C ABI can make the alignment 8 bits or
64 bits or whatever and C++ can mirror that. Nothing is C-incompatible
here.
Received on 2025-09-04 06:15:43