bout BigEndian and LittleEndian

the default on an wintel c++ development tool would be little-endian i would think.

necessary

As someone mentioned, Windows probably defaults to "Little-Endian". It's how Intel CPUs work. The Palm would probably expect "Big-Endian" as Palms used Motorola CPUs and that's how they work. You probably want to ask about this on a Palm Forum. It could be that you might be able to write a Palm Conduit to flip the data bytes around.

It's almost impossible to answer your question as-is, because there is no such thing as a "binary text file". A file can be created in binary mode, or in text mode, which affects the way line ends and potentially the EOF character are handled. A "binary text file" is a self-contradiction in that context.

Pop quiz:

1. What's is the endian-ness of an ARM processor?
2. What does lilliput have to do with and endian?
3. Do you crack eggs at the big end or the little end?

Gary :-)

necessary

Probably it's little-endian, that means LOW byte is firs, and HIGH byte is afterwards.

Yes, find another compiler. Find the right compiler for your target processor.

necessary

Don't know. I think you should find out with which tools are applications for your Palm done with.

We do a similiar process quite often. The idea is that somewhere along the line you are going to need to swap the bytes in the data stream around.

It's arbitrary to decided if it's done on the PC side or the handheld side. Applications I'm involved with usually involve mobile communications to a desktop machine runing a server, so we've arbitrarly decided to do it on the PC side. This offloads the PDA from having to byteswap all incomming and outgoing data, however it's became more arbitrary to us because we now support various other PDA platforms with "the other endian".

Have a look at the functions ntohl(...) and ntohs(...) on the PC side.

On the Palm equivalent functions are part of NetLib and have the names NetNtoHL(...), NetNtoHS(...), NetHtoNL(...) and NetHtoNS(...).

Depending upon your Palm programming environment, your standard C library might provide wrapper functions/macros so that you can call NetNtoHL(...) via it's more traditional name ntohl(...).

The choice of where the conversion is done will also depend on the excate method you intend to use to access this file from the Palm device. For example if you are planning to place it on a memory card and use the VFS library to access it, it might pay to keep it in Little Endian if there is also the chance that the file could be used unmodified by a desktop application.

Hope it helps, Christopher Fairbairn.

Hi, Answer for your first question is, ARM processor supports both the endianness and it is configurable via control registers if required.

Raja

That's true for the CPU core itself. The peripherals around it on the die and the board it's on may only support one mode or the other.

Answer to 1: It's configurable by tying up (or down) a pin.

For 2 and 3: Only an engineer who went to high school in the U.S. and forced to read Gulliver's Travels would readily identify that the Lilliputians (or was it the Brobdingans (sp?) would break their egs at the big end or little end!

For a very interesting dissertation on the subject of endian-ness see the original author's text on the subject titled "On holy wars and a plea for peace" at

Gary

"SARDINE

...snip ....

IIRC Lilliputians were small guys, Brobdignagians were largely horses, and there was another group warring over egg endianism.

IIRC, the egg endian wars were internal rebellions (the emperor declared everyone should break the big end after his son cut his finger breaking the little end, but people resented the order, especially since breaking the little end was traditional). The (neighboring?) realm of Blefescu fomented the rebellions in hopes of gaining some advantage (taking over Lilliput?).

Regards,

-=Dave

Endianness doesnt apply to a file full of bytes. Now if its a file full of 2 byte words or 4 byte longs, it would be nice to know if they were hi byte first or lo byte first. Hi byte first is called 'network order'. Thats how stuff gets sent over networks. Thats a fairly good standard to follow.

BobGardner wrote: : Endianness doesnt apply to a file full of bytes. Now if its a file full of 2 : byte words or 4 byte longs, it would be nice to know if they were hi byte first : or lo byte first. Hi byte first is called 'network order'. Thats how stuff gets : sent over networks. Thats a fairly good standard to follow.

You all talk about endianness from a SW point of view. That is fine per se, as it is in SW that endianness mismatch will have to be fixed anyway. But it is helpful to understand what really goes on from a HW point of view. I have written up a one-page on this isse:

Look at it and tell me what you think. But the point I want to drive home is that Big and Little endian achitectures connected to the same local bus will see exactly the same data in the full natural word width on both sides. The endianness problem only arises when the datasize is smaller than the cores' natural bus width. Or data is somehow transported between them.

It is this dependancy of endianness on actual data width that makes it so hard (impossible) to design HW byte-lane switchers in eg. PCI bridges. A endianness switching scatter-gather DMA transfer breaks down once there is a _mixture_ of data widths in the data block.

(BTW, the one-sheet also mention PowerPC as Big Endian. While this is [usually] true, PPC also has reversed bit notation wich makes comparison difficult.)