Re: An interesting quote on Java and C++

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Robert Duff says

<<> How about integers?  The Java standard nails down integers pretty
> precisely (exactly 8, 16, 32, and 64-bit arithmetic, with wraparound on
> overflow).  Does anybody know whether Java implementations obey this?
> Are there any Java implementations on machines where the word size would
> make this inconvenient?>>

Yes, of course, the wrap around rules assume twos complement arithmetic
and are a major menace on 1-s complement machines.

Early on, when we were designing Ada 9X, the folks at Unisys, one of the
last companies to make 1-s complement machines on a big scale, got hold
of an early version of the proposed standard which allowed only 
2s complement models for modular integers.

I got a call from a huge gang of people at Unisys, including some quite
high up people, expressing dismay at the fact that the new standard
might be incompatible with their hardware (Unisys by the way has
made quite a commitment to Ada over the years, they did a multi-million
deal with Alsys to acquire and port the Alsys technology to their own
back end code generators).

As it turns out, the final Ada-95 (somewhat unwisely in my view, it seems
a gratuitous feature) allows any modulus, so the mod 2**k-1 arithmetic
required for clean wrap around in the 1-s complement case is supported
(thoughy of course in practice every one uses mod 2**k types which will
indeed look horrid on a 1's complement machine). I do not know if Unisys
has made a similar call to the Java folks, or if they still make those
1's complement machines!

Final note: the history of arbitrary moduli is interesting. One mission
of the design team was to follow the recommendations of the URG as far
as possible, and turn these uniformity recommendations into requirements
where possible. For example the (ratther silly) RM requirement that

21   In an implementation, the range of Integer shall include the range
-2**15+1 .. +2**15-1.


derives from this. Why rather silly? Well the actual URG implementaion
recomends 32 bits, but this was perceived as too fierce for a requirement
(no doubt partly because certain persons were interested in 24-bit integers
on the Patriot :-) and that's probably right, 32-bits would have been too
fierce, so it is better as a recommendation. So what hapened here was the
idea of the requirement remained, but the parametrization is gratuitous
(there is no serious possibility of someone choosing less than 16-bits
for Integer anyway).

Anyhow, back to modular types. The URG had been given a design paper
that recommended arbitrary modular types, but it had overwhelmingly
rejected this as unnecessarily complex, and recommended that only
2**K modular types be supported.

Unfortunately, due to a procedural glitch, the design team picked up
the original rejected design paper, and thought it was a URG recommendation,
so in it went, and to the surprise of me and others, survived the pruning
process which removed many frills.

Of course if you find the non-binary modular stuff useful (I wonder how
much it is used outside ACVC tests), then no doubt you regard this as a
lucky mistake :-)