4

I'm considering a very specific (and nowadays useless) processor, called saturn.

One of the strange feature of this CPU is that its element unit is the nibble (4-bits), not the byte (8-bits). It's not just cosmetic, any pointer value is expressed in nibble.

There was one attempt at creating a C compiler for Saturn : hp48xgcc

Looking at its documentation, I noticed that its basic types follow the usual GCC convention, with char 8 bits. At this point, I wondered : Is it not the intention of CHAR_BIT to provide the size of the element unit ? This seems to be hinted by GCC own documentation :

You can compute the number of bits in any data type like this:
      sizeof (type) * CHAR_BIT

In this case, considering the Saturn architecture, it would be better to have CHAR_BIT = 4

Or do I misunderstand the signification of CHAR_BIT ?

Cyan
  • 13,248
  • 8
  • 43
  • 78
  • Related: http://stackoverflow.com/questions/881894/is-char-guaranteed-to-be-exactly-8-bit-long-in-c – dan04 Aug 30 '13 at 16:44
  • 1
    I don't know the details of the history of C standard(s), but IMHO you're right about the rationale for `CHAR_BIT`: it should represent the width of the smallest addressable unit on the machine. Alas it seems that the extensors didn't consider systems with unit that narrower. I'm not sure, but nowadays there are probably very few (if any) CPUs/SOCs/Micros with units that narrow. The only funny thing is that the Saturn (the CPU of old HP48 scientific calculators IIRC) was used in the early 90s, so after the first standard was finalized. I wonder how many CPUs had so small units at the time. – LorenzoDonati4Ukraine-OnStrike Aug 30 '13 at 17:01
  • 2
    Of course, just because the C standard does not "support" this, there's no law saying you can't butcher, er, I mean "customize" an open-source C compiler to do it. Though there would be challenges there would also be advantages. Just be aware that conventional character strings will not work, nor will many "canned" packages and tools,. – Hot Licks Aug 30 '13 at 17:10
  • 1
    A C implementation can simply ignore this gratuitous CPU quirk and define `CHAR_BIT` as 8. Odd pointer representations would then simply never be used; the low bit of all pointers would be zero. Access to `char` would really access two nibbles, and all larger types would be in units of `char`, as required by C. – R.. GitHub STOP HELPING ICE Aug 30 '13 at 17:17
  • having a 4 bit byte makes a lot of sense for a BCD unit... seems like you have a couple of options (pad each byte, just like lots of architectures do for (int16, short) etc.) or deal with an address in some convoluted way: like the sign bit really represents the high or low nibble of the C addressed byte. or define a SByte as int:4... or just deal with asm like you probably should in such microland. – Grady Player Aug 30 '13 at 17:27
  • HP's Saturn CPU has built-in BCD arithmetic. It does only use 10 of the potential 16 values of a 4-bits nibble. So a 64-bits BCD integer value is really 16 digits (16x4=64). – Cyan Sep 02 '13 at 11:38

2 Answers2

11

No. According to C99 standard CHAR_BIT minimum value is 8 (BTW, this is true also for C89/90).

The relevant section of the C99 draft standard (WG14/N1256) is the following:

5.2.4.2.1 Sizes of integer types

The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions that have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

— number of bits for smallest object that is not a bit-field (byte)

CHAR_BIT             8

LorenzoDonati4Ukraine-OnStrike
  • 6,875
  • 4
  • 37
  • 56
5

No. CHAR_BIT is guaranteed to be at least 8 bit on all compilers supporting the C89 standard or later.

Hampus Nilsson
  • 6,692
  • 1
  • 25
  • 29