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,70016ed51014902d X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Warning: Flame Bait Date: 1996/11/30 Message-ID: #1/1 X-Deja-AN: 201573250 references: <01bbdcb5$7500ab30$24af1486@pc-phw> organization: New York University newsgroups: comp.lang.ada Date: 1996-11-30T00:00:00+00:00 List-Id: Bob says "Quite true. Portability in practice is quite different from portability in theory. Java has the "theory" part done quite nicely -- a Java program that works properly on one machine will work the same on any other machine that correctly supports the Java language (except for issues involving shared variable updates by multiple threads). You can't say that about Ada, since Ada doesn't define lots of things (order of evaluation of arguments, pass-by-reference vs. pass-by-value, semantics of arithmetic overflow, etc -- I could name several tens of cases). On the other hand, if a Java compiler doesn't exist on your machine, you're out of luck. Likewise, if your machine doesn't have a word size that is a power of 2, Java can't be compiled efficiently for it. The designers of Java clearly valued portability above all else, including efficiency, and there are many situations where Java simply is inappropriate." Well you can always make a language portable on paper by specifying everything in great detail, that would for example have been trivial to do in Ada 95, BUT, and this is a *huge* but, the consequence of doing so is that efficient implemenations become impossible on many machines. Now of course, so far we have only (by conventional compiler standards) ludicrously inefficient interpreted implementations of Java, where such details are largely buried by the interpretive overhead. But when people start writing, or rather trying to write, efficient Java compilers, the problems will be more than expected. Bob wonders if Java will be the final nail in the coffin for "weird" machines? The trouble is that when you pin down the semantics as far as Java has, then a lot of machines become weird. For example, all DEC Alpha's and the high end MIPS chip (R10000) are both weird by this definition, because they do not quite implement the whole of the IEEE floating-point standard. If you are serious about Java requiring strict adherence to the IEEE standard, then it will be impossible in either of these cases to provide this strict adherence without a huge loss of efficiency (just try running your favorite Fortran codes on a DEC Alpha in strict IEEE mode, and you will see what I mean). Now, it is certainly trivially easy when designing a language to make a statement that FPT will be exactly IEEE 754, and then congratulate yourself for doing such a splendid job of portability design, but if what you have achieved is a design that does not run correctly on the machines that people think of as being appropriate for high end fpt calculations (Sun is not a big player in this market), then perhaps you have not done such a great job after all. You have to know a LOT to avoid such mistakes. My guess is that the folks at Sun who specified IEEE floating-point were simply unaware of the consequences (it is possible that this was a subtle way of designing a language more amenable to Sun than to SGI or DEC, but I doubt it was well enough informed to have been so clever :-) In the Ada world, a similar though smaller scale glitch happened with floating-point. In Ada 83, division of floating-point values must be exact if the result is a model number. Sounds reasonable, BUT, it means that you cannot implement Ada 83 efficiently on a Cray (or for that matter on an Intel i860). In the Ada 95 standard, there is a new "feature" (RM G.2.1(16)) Implementation Permissions 16 If the underlying floating point hardware implements division as multiplication by a reciprocal, the result interval for division (and exponentiation by a negative exponent) is implementation defined. Now from one point of view, this means that Ada is getting worse from a portability point of view, but in pragmatic terms it makes Ada more portable, because it makes it practical to implement Ada efficiently on such machines. Sure there are very unusual cases of code that depend on the old rule, but it is better to have a very minor portability glitch of this kind, rather than a situation where NO Ada code runs acceptably efficiently on a whole class of machines!