From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Sat Jan 10 2004 - 17:50:00 EST
From: "Clark Cox" <clarkcox3@mac.com>
> Actually, both the C and C++ standards require that the char type be
> at least 8-bits. that is, the signed char type must be able to
> represent the values in the range [-127, 127], and the unsigned char
> type must be able to represent the values in the range [0, 255]. Any C
> or C++ compiler that cannot meet those requirements is non-conformant.
Yes of course (however this depends on which standard you discuss here...
The language itself does not require it, just the implementation guidelines
for applications on generic OS.
If you look at some C compilers created for microcontrolers or hardware
devices, you'll see that it supports the full core language, but not always
with the "standard" library which usually comes bundled with compilers for
generic OS platforms, because this library is too fat to be incorporated in
the device's firmware).
You'll see for example that most BIOS software is written today with a
significant part written in C, because it's easier to maintain than assembly
language when optimal performance is not a real issue. But the same BIOS
will typically never use the standard library. And so a C compiler tuned for
writing a BIOS software may ignore the library requirements defined in a C
standard made for applications supported by general purpose OS.
In such cases, as soon as you start ignoring the POSIX standard (which is
not by itself part of the core C language), you can't assert that "char"
needs to be at least 8 bits. The compiler may be tuned specially to support
the native pointer types, which may use actual physical memory units smaller
than 8 bits.
The case of bit-adressable memory is intersting here: why do we need in
C/C++ to handle individual bits with tricky shift operations if the native
platforms could allow you to adress each bit individually or in groups not
aligned on char boundaries? This is a performance problem for hardware
devices that require faster computing with a microcontroler allowing
operations on unaligned bit patterns.
This performance problem also affects generic pieces of geral purpose
softwares like data compressors, and protocol stacks, full of tricky shift
operations that are hard to write cleanly and debug. With bit-addressable
memory and processor instructions designed to read/write/operate on
unaligned groups of bits simply by their starting address, without needing
shift and mask instructions, the code could be much cleaner and faster. And
I don't think that C/C++ can't be used to write software for a
bit-addressable environment (i.e. with a native and complete support for bit
pointers, instead of just char pointers).
This archive was generated by hypermail 2.1.5 : Sat Jan 10 2004 - 18:35:11 EST