I think I agree with everything in Ion's email, especially that the ability
to detect padding bits is useful, and that banning CHAR_BIT>8 is probably a
bad idea.

One wrinkle in the goal to standardize 2's complement is the ability to
reinterpret the bytes of a negative integer as an array of chars: that
seems harder to emulate, and possibly less needed to allow programs to have
portable behavior. If we have functions to serialize and deserialize as
2's-complement byte arrays, we may not need the ability to memcpy as them.
2's-complement behavior in conversions and bitwise operations may be enough.
On Oct 27, 2013 3:46 PM, "Ion Gaztañaga" <igaztanaga_at_[hidden]> wrote:

> El 27/10/2013 18:12, Jeffrey Yasskin escribió:
> > And AFAICS they didn't bother to implement a C++ compiler at all,
> > indicating to me that the niche for C is that of being easy to
> > implement, not that of supporting more machines (since it _doesn't_
> > support the efficient mode for this machine).
> >
> > If we make the C++ definition stricter, either unusual machines will
> > keep implementing just C because it's still easier, or they'll
> > implement a non-conforming mode for C++ as the default and a
> > conforming mode as a switch, just like they do for C.
>
> I think we have two separate issues here. We might have a different
> answer to each question:
>
> 1) One's complement, sign-magnitude / padding bits
>
> Non two's complement (with/without padding bits) machines seem to be old
> architectures that have survived until now in some sectors (government,
> financial, health) where backwards compatibility with old mainframes is
> important.
>
> Unisys was formed through a merger of mainframe corporations
> Sperry-Univac and Burroughs, so Clearpath systems are available in two
> variants: a UNISYS 2200-based system (Sperry, one's complement 36 bit
> machines) or an MCP-based system (Burroughs, sign-magnitude 48/8 bit
> machines). According to their website, new Intel based mainframes are
> being designed (so they'd need to emulate 1's complement /
> sign-magnitude behaviour though the compiler). They have no C++ compiler
> and Java is executed with additional 2's complement emulation code. They
> are migrating from custom ASICs to Intel processors
> (http://www.theregister.co.uk/2011/05/10/unisys_clearpath_mainframe/) so
> 2's complement will be faster in newer mainframes than 1's complement.
>
> I think requiring 2's complement in the long term would be a good idea,
> even in C, as no new architecture is using other representation and this
> simplifies teaching and programming in C/C++. We could start having a
> ISO C macro (for C compatibility) to detect 2's complement at compile
> time and deprecate 1's complement a sign-magnitude representations for
> C++. If no one objects then only 2's complement could be allowed for the
> next standard.
>
> It would be interesting to have more guarantees on 2's complement
> systems (say no padding bits, other than in bool), but I don't know if
> that would be possible as I think there are Cray machines with padding
> bits in short/int pointers types:
>
>
> http://docs.cray.com/books/004-2179-001/html-004-2179-001/rvc5mrwh.html#QEARLRWH
>
> At least it would be interesting to have a simple way to detect types
> with padding bits.
>
> 2) CHAR_BITS > 8
>
> Architectures with CHAR_BIT > 8 are being designed these days and they
> have a very good reason to support only word (16-24-32 bit) based types:
> performance. Word-multiple memory accesses and operands simplify the
> design, speed-up and allow bigger caches and arithmetic units, they
> allow fetching several instructions and operands in parallel more easily
> and use every transistor to do what a DSP is supposed to do: very
> high-speed data processing.
>
> These DSPs have modern C++ compilers (VisualDSP++ 5.0 C/C++ Compiler
> Manual for SHARC Processors,
>
> http://www.analog.com/static/imported-files/software_manuals/50_21k_cc_man.rev1.1.pdf
> ).
>
> "Analog Devices does not support data sizes smaller than the addressable
> unit size on the processor. For the ADSP-21xxx processors, this means
> that both short and char have the same size as int. Although 32-bit
> chars are unusual, they do conform to the standard"
>
> "All the standard features of C++ are accepted in the default mode
> except exception handling and run-time type identification because these
> impose a run-time overhead that is not desirable for all embedded
> programs. Support for these features can be enabled with the -eh and
> -rtti switches."
>
> In DSPs that can be configured in byte-addressing mode (instead of the
> default word-addressing mode) stdint.h types are accordingly defined
> (int8_t and friends only exist in in byte addressing mode). Example:
> TigerShard DSPs (VisualDSP++ for TigerSharc processors:
>
> http://www.analog.com/static/imported-files/software_manuals/50_ts_cc_man.4.1.pdf
> ).
> Even pointer implementations are optimized for Word-addressing (taken
> from the C compiler manual):
>
> "Pointers
>
> The pointer representation uses the low-order 30 bits to address the
> word and the high-order two bits to address the byte within the word.
> Due to the pointer implementation, the address range in byte-addressing
> mode is 0x00000000 to 0x3FFFFFFF.
>
> The main advantage of using the high-order bits to address the bytes
> within the word as opposed to using the low-order bits is that all
> pointers that address word boundaries are compatible with existing code.
> This choice means there is no performance loss when accessing 32-bit items.
>
> A minor disadvantage with this representation is that address arithmetic
> is slower than using low-order bits to address the bytes within a word
> when the computation might involve part-word offsets."
>
> I think banning or deprecating systems with CHAR_BIT != 8 would be a
> very bad idea as C++ is a natural choice for high-performance
> data/signal processors.
>
> Best,
>
> Ion
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>