On Wednesday, 16 July 2025 08:25:34 Pacific Daylight Time Jan Schultke wrote:
> > And how is the situation different from DSP or other unusual architectures
> > with 8-bit bytes? The effort is the same to support <simd>: massive, per
> > architecture, and provided by those who are interested.
>
> There's a much greater chance that you can piggy-back off of existing
> implementations. If your architecture has 8-bit bytes, you can write
> an LLVM backend. I don't think LLVM supports non-8-bit bytes right
> now, or will do so in the near future. With LLVM, <simd> can use
> clang's vector_size attribute, and you get the frontend of <simd> for
> free.

So there's little chance LLVM would support this DSP in the first place,
whether CHAR_BIT is required to be 8 or not, whether <simd> is part of the
Standard or not. That means the above is an interesting factoid and indicates
how little attention those platforms are getting, but is orthogonal to the
discussion.

> If you don't have 8-bit bytes, you operate outside of the widespread
> software stack into which thousands, if not millions of work hours
> have been sunk; you start from nothing.

True.

But again, orthogonal.

The question is whether there is anyone who *does* support non-8-bit-bytes and
could want to update to C++29 in the next 25 years. What is their opinion on
<simd>? And as I asked at the beginning of this thread: what do we gain by
enforcing this? What can we do that we could not before?

Let's say it could simplify the networking stack, in spite of there being
networking stacks on non-8-bit-platforms. We could make the stack optional by
making it dependent on uint8_t, without affecting the rest of the Standard.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering