C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Restrict possible values of CHAR_BIT
From: Tom Honermann (tom_at_[hidden])
Date: 2019-10-28 08:46:30


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
>



STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups