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: bobduff@world.std.com (Robert A Duff) Subject: Re: Endian and Ada Date: 1996/04/10 Message-ID: X-Deja-AN: 146652272 references: <4kamb9$om2@flute.aix.calpoly.edu> <4kevdl$254a@flute.aix.calpoly.edu> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-04-10T00:00:00+00:00 List-Id: In article <4kevdl$254a@flute.aix.calpoly.edu>, Michael Anthony Porcelli 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