On 01/07/2025 07:12, Thiago Macieira via Std-Proposals wrote:
> On Monday, 30 June 2025 06:01:34 Pacific Daylight Time Matthew Taylor via Std-
> Proposals wrote:
>> they are permanently on C++98/03 and so there is little point in changing
>> how we design C++26 or C++29 to account for them.
>
> But unless the architectures themselves are end-of-lifed, we can't guess the
> future. There could be a point when there's a requirement from their users to
> update, but that can only happen if it is still possible.
>

(This is all based on my experience and reasoning - I have no special
inside information.)

The architecture in question is not end-of-lifed, as far as I know. And
predicting the future is always hard.

However, it /is/ somewhat of a dead-end architecture in many ways. Like
almost all current devices with a CHAR_BIT greater than 8, it is a DSP
core. DSP cores have moved steadily towards niche usages for the past
couple of decades. They are still produced, sometimes in very large
numbers, but there are only a very few people who program them - since
general purpose cores gained multiply-accumulate instructions, SIMD,
etc., you need a /very/ good reason for choosing to work with DSP cores.
  For most customers buying DSPs, they buy ready-made software too, and
do not do the development themselves.

The Texas Instruments TMS320 family mentioned here is probably the
remaining DSP family with the most significant user-base. The reason
for that is the microcontrollers - they are very robust (with many
high-temperature variants) and have a good selection of peripherals.
They are used despite the cpu core, not because of it - no design team
would pick them for a new project unless they needed the high robustness
or had significant investment in existing tools, familiarity, and code.

DSP tools are updated with bug fixes, and support for newer hardware
devices. They will sometimes gain new features that customers want,
such as profiling or debugging enhancements. On rare occasions, they
will gain new optimisations to improve code generation. But very few
customers will be interested in newer C or C++ standards, however - they
are not particularly relevant for these kinds of devices and the kinds
of tasks they are used for. Indeed, C++ is a rarity in DSP work - much
of it is either in assembly or C, with heavy use of very device-specific
intrinsics. (If you are not using these, there is no point in using a
DSP in the first place.) The compilers are written specifically for
these devices - they are not ports of generic tools, because the cores
are too different from "standard" cpu cores.

So supporting new C++ standards would be hugely expensive, and only of
interest to a very small proportion of their small developer base.

Add to that, TI does not have a reputation for embracing new standards -
or even for being particularly careful about following older ones. The
majority of their microcontrollers have ARM cores or MSP430 cores, but
the main toolchains provided by and supported by TI are long out of date
regarding standards - C++14 seems to be the most recent support. There
can be multiple reasons for this, and their main customers may not be
asking for newer standards support (embedded developers favour stability
and reliability over new and fancy).

So will TI ever make a toolchain for the TMS320 family with C++29 if
C++29 continues to support 16-bit bytes? I believe we can confidently
say no, it will never have C++29 support. I do not believe C++29 will
ever be seriously supported on any device with CHAR_BIT > 8, regardless
of whether or not the standard restricts CHAR_BIT.

Of course, I still think it would be a good idea to ask the opinion of
TI, Analog Devices, NXP, and others before committing to 8-bit bytes.

> In any case, how does the standard change in any way by requiring 8-bit bytes?
>

I think the main advantage is aligning the C++ standards with what the
vast majority of C++ programmers see as reality - bytes are 8 bits. I
can't see any practical disadvantages, but that does not mean it would
be worth the effort.