On 06/09/2025 01:50, Thiago Macieira via Std-Proposals wrote:
> On Friday, 5 September 2025 09:40:36 Pacific Daylight Time Jason McKesson via
> Std-Proposals wrote:
>> I understood that we were discussing some microcontroller architecture
>> with direct support for SHA registers and processing. Something that's
>> attached to the CPU and thus is effectively a part of the platform, or
>> is just a novel processor entirely. Such a platform would have its own
>> ABI, and it therefore has the freedom to assign the alignment of
>> `_BitInt(384)` whatever it feels is most efficient. It would not be
>> expected to be ABI-compatible with other architectures.
>>
>> That is, we're not talking about slapping some SHA-accelerator card
>> into your average PC.
>
> It's highly unlikely that a SHA-384 register would be used for _BitInt in the
> first place. Such a specialised register would not be useful for generic
> operations.
>
> Moreover, any platform with SHA acceleration is likely going to have low
> alignment requirements for the input, because most checksums are at unaligned
> content. At worst, it will have typical alignment for large data blocks,
> usually the size of the machine's word.
>
>

I believe there has been a lot of confusion about the idea of using
"unsigned _BitInt(384)" for SHA acceleration, and I will try to clarify
a little. I know some people understand more than others - I am not
writing this specifically targeting any one poster or reader here.

When I mentioned it, it was in the context of FPGA design. This is not
about using C++ on a CPU that has an SHA accelerator of some sort, or a
microcontroller with an SHA peripheral, or a processor with 384-bit
registers.

The use I mentioned is for FPGA (or other hardware) /design/. It is not
for writing software on existing hardware, but for designing new
hardware. Traditionally, FPGA designs have been done using hardware
design languages - mostly Verilog and VHDL. In more recent times, a lot
more has been done using high-level languages - sequential imperative
languages (such as C, C++, Python), functional programming languages
(like Haskell) or mixed languages (like Scala) - to do the design. The
aim is to be able to do more emulation and testing during the design,
and to more easily take existing software algorithms and turn them into
faster dedicated hardware.

So when your FPGA design code in C++ uses a _BitInt(384) local variable,
it is not put in a register - it /becomes/ a register. Alignment is
irrelevant - it is not in memory. Or if you have an array of
_BitInt(384) types declared in a way that would be in memory in normal
C++, it becomes a dedicated 384-bit wide memory block in the FPGA design.

When you use exactly the same C++ code with a normal C++ compiler on a
desktop computer, you do so for simulation and testing so that you can
be sure that the generated hardware will do the job you want. Speed and
efficiency considerations are secondary now, but it is important that
the types and operations used in the hardware design work in the same
way when simulating.