On Mon, 29 Apr 2002 09:22:01 -0400, Eric L. Strobel wrote:
>
>on 4/28/02 4:33 AM, Robert Benschop at rbenschop_at_mac.com wrote:
>
>>
>> Since we're a small community we will probably all benefit with shared
>> efforts (even if I don't have a clue what 'endian-safe' is ;-)
>>
>
>If you have a two byte entity in memory (say an integer), you can either
>store all 16 bits in order, i.e., 15-14-13-...-2-1-0, OR you can store
>things as if you're going to work a byte at a time, i.e.,
>7-6-5-...-1-0-15-14-...-9-8. If I haven't suffered a parity reversal in my
>grey matter, these are referred to (respectively) as little-endian and
>big-endian. Intel chips use the big-endian (or did I screw that up??) and
No, little endian, because the least significant byte (the most little
value) comes first.
>PPC, RS##### (Silly-G's), and some others use the other convention. I don't
>recall what convention SPARCs or Alpha's use. Or, more apropos to our
SPARC, don't know. Alpha can do both.
>discussion, I don't know the convention used on the Newt. But the few times
Newt is like the rest of the world and specially Apple Big-Endian.
>I've ever had to deal with swapping data with Wintel machines, I seem to
>recall that this appeared to be an Intel vs. the-rest-of-the-universe sort
>of thing. I think it stems from when Intel chips were transmogrified from
>8-bit to 16-bit.
Correct. That was built into the 8086/88 to be compatible with the
8080. Sounds familiar, eh?
>
>Please, I'm not a CS, nor do I play one of TV, so those that know this
>better, please jump in!
>
>Bottom line: When dealing with raw data in 2,4, or 8-byte entities that is
>passing between Wintel and other platforms, one must examine this issue and
>will likely need to insert some "IF Wintel THEN byte-swap" code.
Yes. If you have to actually calculate with it.
Jochen
-- Read the List FAQ/Etiquette: http://www.newtontalk.net/faq.html Read the Newton FAQ: http://www.guns-media.com/mirrors/newton/faq/ This is the NewtonTalk mailing list - http://www.newtontalk.net
This archive was generated by hypermail 2.1.2 : Sun May 05 2002 - 14:05:24 EDT