Re: Warning: Flame Bait

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

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!