strangest systems I've sent email from

[Sean Conner]

It was thus said that the Great Mouse once stated:
> >>>   -spc (Wish the C standard committee had the balls to say "2's
> >>>   complement all the way, and a physical bit pattern of all 0s is a
> >>>   NULL pointer" ... )
> >> As far as I'm concerned, this is different only in degree from `Wish
> >> the C standard committee had the balls to say "Everything is x86".'.
> 
> > First off, can you supply a list of architectures that are NOT 2's
> > complement integer math that are still made and in active use today?
> 
> > Second, are there any architectures still commercially available and
> > used today where an all-zero bit pattern for an address *cannot* be
> > used as NULL?
> 
> What's the relevance?  You think the C spec should tie itself to the
> idiosyncracies of today's popular architectures?

  I'd wager that most C code is written *assuming* 2's complement and 0 NULL
pointers (and byte addressable, but I didn't ask for that 8-).  That the C
Standard is trying to cover sign-magnitude, 1's complement and 2's
complement leads to the darker, scarier, dangerous corners of C programming.

  I've been reading some interesting things on this.  

	"Note that removing non-2's-complement from the standard would
	completely ruin my stock response to all "what do you think of this
	bit-twiddling extravaganza?" questions, which is to quickly confirm
	that they don't work for 1s' complement negative numbers. As such
	I'm either firmly against it or firmly in favour, but I'm not sure
	which."

	...

	"[W]rite a VM with minimal bytecode and that uses 1s' complement
	and/or sign-magnitude. Implement a GCC or LLVM backend for it if
	either of them has nominal support for that, or a complete C
	implementation if not. That both answers the question ("yes, I do
	now know of a non-2's-complement implementation") and gives an
	opportunity to file considered defect reports if the standard does
	have oversights. If any of the defects is critical then it's
	ammunition to mandate 2's complement in the next standard."

	http://stackoverflow.com/questions/12276957/are-there-any-non-twos-complement-implementations-of-c?lq=1

  Personally, I would *love* to see such a compiler (and would actually use
it, just to see how biased existing code is).  From reading this
comp.lang.c++.moderated thread:

	https://groups.google.com/forum/?hl=en&hl=en#!topic/comp.lang.c++.moderated/gzwbsrZhix4

I'm not even sure 

	size_t foo = (size_t)-1;

is legal, or even does what I expect it to do (namely---set foo to the
largest size_t value possible (pre C99).

  Now, I realize this is the Classic Computers Mailing list, which include
support for all those wnoderful odd-ball architectures of the past, but
really, in my research, I've found three sign-mangnitude based computers:

	IBM 7090
	Burroughs series A
	PB 250

(the IBM 1620 was signed-magnitude, but decimal based, which the C standard
doesn't support.  And from what I understand, most sign-magnitude based
machines were decimal in nature, not binary, so they need tno apply)

and a slightly longer list of 1's complement machines:

	Unisys 1100/2200
	PDP-1  
	LINC-8
	PDP-12  (2's complement, but also included LINC-8 opcodes!)
	CDC 160A
	CDC 6000
	Electrological EL-X1 and EL-X8

I won't bother with listing 2's complement architectures because the list
would be too long and not at all inclusive of all systems (but please, feel
free to add to the list of binary sign-magnitude and 1's complement
systems).  Of the 1's complement listed, only the Unisys is still in active
use with a non-trivial number of systems but not primarily emulated.

  To me, I see 2's complement as having "won the war" so to speak.  It is
far from "idiosyncratic." And any exotic architecture of tomorrow won't be
covered in the C standard becuase the C standard only covers three integer
math implementations:

	signed magnitude
	1's complement
	2's complement

If tinary or qubit computers become popular enough to support C, the C
standard would have to be changed anyway.

  The initial C standard, C89, was a codification of *existing* practice,
and I'm sure IBM pressed to have the C standard support non-2's complement
so they could check off the "Standard C box."  Yes, Unisys has a C compiler
for the Unisys 2200 system and one that is fairly recent (2013).  But I
could not find out if it supported C99, much less C89.  I couldn't tell.  

  And yes, you can get a C compiler for a 6502.  They exist.  But the ones
I've seen aren't ANSI C (personally, I think one would be hard pressed to
*get* an ANSI C compiler for a 6502; it's a poor match) and thus, again,
aren't affected by what I'd like.

  I'm not even alone in this.  Again, for your reading pleasure:

	Proposal for a Friendly Dialect of C
		http://blog.regehr.org/archives/1180

	The Problem with Friendly C
		http://blog.regehr.org/archives/1287

  Both are written by a professor working on tools to make using C safer.

> > [3]	I only bring this up because you seem to be assuming my
> >       position is "all the world's on x86"
> 
> No, I don't think that's your position.  I'm using that as a satirical
> exaggeration of your position.  If I'd been writing this twenty years
> ago, I would have written "VAX" instead, because that was the machine
> widely assumed at the time.

  Twenty years ago, the "all the world's on x86" (1996).  *Thirty* years
ago, and yes, I would agree 8-P

  -spc