Re: Endian and Ada

[bobduff@world.std.com (Robert A Duff)]

In article <4kevdl$254a@flute.aix.calpoly.edu>,
Michael Anthony Porcelli <mporcell@flute.aix.calpoly.edu> wrote:
>1.  Endian becomes an issue when cross platform data distribution/transfer
>is involved regardless of what programming language is used.

Correct.  This is the "hard problem".

>2.  It *is* possible to write "endian free" code in any language (possibly
>not assembly).  I'm not saying, however, that it's possible to write *all* 
>software "endian free" but that it's possible to write *some* software "endian 
>free".  This is done fairly simply by just not writing code that depends on 
>byte-ordering.  What I mean by "endian free code" here is that if the code
>was compiled and run on a big endian computer, that the same code would
>compile and run successfuly (and identically) on a little endian computer 
>(assuming all other non-endian cross-platform problems are non-existant).

Correct.  It's pretty easy to do this in Ada or C or C++.

>3.  It is possible to write non-"endian free" code in any language that
>allows direct byte manipulation.  C and C++ definitely allow this.  I do
>believe that Ada allows this (unchecked programming).  Am I correct here?

Correct.  The nice thing about Ada is that when you write
system-dependent code, you normally say so explicitly in the source
code.  In any case, it's certainly possible to write such code in Ada.

>4.  Whenever possible, write "endian free" code.  This seems to me to be
>simply good software-engineering practice.  It also seems to me that most,
>if not all software applications (with the possible exception of systems
>software) can be written "endian free".  Perhaps efficiency might be
>sacrificed from time to time, but the portability is worth it.

Right.  I don't think efficiency is even a big issue here.  (Assuming
you're not passing data to a different-endian machine.)

>5.  This is kind-of my big question here.  Can systems software be written
>without depending on byte-ordering?  I have basically no experience writing
>systems software so I have no idea here.  It seems that if the answer is
>yes, then it's only a matter of bad software engineering that byte-order
>dependant code is still written (except for software that manipulates
>cross-platform data transfer, #1 above).  If the answer is no, then porting
>systems software becomes a royal pain (according to my understanding, it
>is as a direct result of the endian problem.)

Yes, even system software can, and should, be written to work properly
on either endian machines.

>6.  The Java solution.  I guess my question is whether or not that Java
>"platform" is a solution to this.  In case you haven't heard, Sun is making
>processors that run Java byte-code directly.  My guess would be that the
>choice of "big" or "little" endian is part of the Java platform architecture
>standard (I don't know this for sure).  If, in fact, this is true, *and* if
>the whole world follows suit (making Java-native processors) then it seems
>that the endian problem would "go away" (eventually).  What I'm not talking
>about here is the Java language itself.  There doesn't seem to be a need to.
>According to my understanding it is completely "safe", i.e. allows no
>facilities at all for writing unchecked byte-manipulating code.

I don't know enough about Java to say anything here.

>7.  Processors that switch from big to little.  I've only heard of these and
>I don't know if they are actually out on the market yet.  I do believe that
>HP (and others) are working on making architectures that can run in either
>big or little endian mode.  One of the main reasons that this is being done
>is the possibility that Windows is going to take over the world.  It seems
>that the powers-that-be feel that making a switchable architecture is easier
>than re-writing windows to be big endian.  I'd appreciate hearing any more
>on this from someone who has worked with these type of processors or has any
>more information regarding this trend.  Personally, I'd hate to see
>Microsoft completely take over the systems software market, but it seems
>that is the way things are going.

Yes, processors that switch endian-ness exist, and are on the market.
However, the O.S. usually sets the processor to one particular
endian-ness, and assumes that forever.  It's easy to write an OS that
works properly with either endian-ness, assuming you recompile the OS
for whichever one; it's not so easy to write an OS that can switch back
and forth.

And yes, Microsoft will probably take over the world.

- Bob