On 10/24/19 4:52 PM, Arthur O'Dwyer via Std-Proposals wrote:
> On Thu, Oct 24, 2019 at 4:10 PM Tjernstrom, Staffan via Std-Proposals
> <std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>> wrote:
>
> Looking at interactions with (and by extension, programming on)
> FPGAs, where everything is bit-based, it's common to find things
> like 14-bit values. We have 14-bit types in our internal type system.
>
>
> Yes, but "a 14-bit type exists" is not the same thing as
> "CHAR_BIT==14". I would be as surprised as Lyberta (and perhaps more
> so) if any C++ compiler in the world supported "CHAR_BIT==14".
>
> However, I agree with Tom that this proposal is not motivated.
> Personally I think it'd be just as silly to have CHAR_BIT==16 or
> CHAR_BIT==32 as to have CHAR_BIT==9 or CHAR_BIT==24. If we're trying
> to get C++ to fall in line with what "everybody knows," then the way
> to do that is to mandate CHAR_BIT==8, not to keep the current
> situation of "CHAR_BIT==I don't know, ask your vendor" but also put
> odd restrictions on the vendor's choice.
>
> Lyberta, did your survey turn up any C++ implementations where
> CHAR_BIT != 8? If so, what version of C++ were they — C++03, 11, 14, 17?

Coverity supports a number of compilers where byte size is not 8. I'm
not very familiar with these compilers and I don't know which ones (if
any) are being maintained. Ones I know of are for targeting the
following DSPs. The Analog Devices ones have a 32-bit char, the rest
are 16-bit.
- Analog Devices:
    - 21XX
    - TigerSHARC
- CEVA
    - TeakLite 4
- Texas Instruments:
    - C2000
    - C54XX
    - C5500

Additionally, there are apparently people working on LLVM targeting an
architecture with a 257 bit byte (that is not a typo).
- http://lists.llvm.org/pipermail/llvm-dev/2019-October/136115.html

Please don't underestimate the potential for C++ to be used for unusual
architectures. It is hard to predict what might become mainstream one day.

As an example provided to me by another committee member recently,
consider some possibilities of a 48-bit processor. 32-bits is often less
than is needed for memory use or floating point precision. But 64-bits
is often more than is needed. A 48-bit processor could hit a sweet
spot. That could in turn lead to a desire for a UTF-12 encoding and a
12-bit char size that would more efficiently encode text (in some cases)
than UTF-8 does today. I'm not stating this would be a good idea, but
it is an example that can be defended in principle.

Tom.

>
> my $.02,
> –Arthur
>