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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9ae3749ddf1e6022 X-Google-Attributes: gid103376,public From: mporcell@flute.aix.calpoly.edu (Michael Anthony Porcelli) Subject: Re: Endian and Ada Date: 1996/04/09 Message-ID: <4kevdl$254a@flute.aix.calpoly.edu> X-Deja-AN: 146639921 references: <4kamb9$om2@flute.aix.calpoly.edu> organization: California Polytechnic State University, San Luis Obispo nntp-posting-user: mporcell@flute.aix.calpoly.edu newsgroups: comp.lang.ada Date: 1996-04-09T00:00:00+00:00 List-Id: 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