From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f3f9104dada53163 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: An interesting quote on Java and C++ Date: 1997/09/20 Message-ID: #1/1 X-Deja-AN: 274111099 References: <5ujjvq$t4s@drn.zippo.com> <34160feb.36797713@news.mindspring.com> <34218E68.63D5@gsg.eds.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-09-20T00:00:00+00:00 List-Id: 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 :-)