Re: Endian and Ada

[mporcell@flute.aix.calpoly.edu (Michael Anthony Porcelli)]

Newsgroups: comp.lang.ada
Subject: Re: Endian and Ada
Summary: 
Expires: 
References: <4kamb9$om2@flute.aix.calpoly.edu>
Sender: 
Followup-To: 
Distribution: world
Organization: California Polytechnic State University, San Luis Obispo
Keywords: 
Cc: 

After reading your posts and thinking about this issue more I think that
perhaps I've come to a better understanding of this issue and, I have come
up with more questions (clearer and more specific ones).  I'm wondering if
you all could check my understanding and let me know if it's correct or not.

1.  Endian becomes an issue when cross platform data distribution/transfer
is involved regardless of what programming language is used.

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).

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?

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.

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.)

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.

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.

Again, thanks for your responses to my original post.  Any comments or
corrections to my understanding would be greatly apreciated (that's mainly
why I'm posting).  

Laters,

-Mike