Does Keil 51 Compiler store ints/longs as Little or Big Endian ?

Anton Erasmus

unread,

Mar 8, 2003, 9:33:38 AM3/8/03

to

Hi,

I am porting some code that was originally written for Keil 51
Compiler. There are quite a number of reasonably complex
#defines with unions and structures. Knowing whether the Keil 51
stored data bigger than 8bits as Big- or Little Endian would help.
So i'd appreciate it if someone who has the Keil compiler can give me
the answer.

Regards
Anton Erasmus

Anthony Fremont

unread,

Mar 8, 2003, 10:27:20 AM3/8/03

to

Big according to this:

http://www.keil.com/support/docs/899.htm

Little according to this:

http://www.keil.com/support/docs/730.htm

It's apparently dependant upon the compiler version. I have the
compiler, but can't remember how it was on my version. I do remember
that I chose to use char arrays, unions and special handling routines to
keep the code as platform and compiler independant as possible.

--
michael brown

"In the land of the blind, he who has one eye is king"

Karl Olsen

unread,

Mar 8, 2003, 10:54:52 AM3/8/03

to

Anton Erasmus wrote:

Keil C51 version 5.50 (which I use) and older versions, use big endian. I
haven't seen any information from Keil about newer versions that they should
have changed that.

Karl Olsen

Paul J. Bosselaers

unread,

Mar 8, 2003, 6:54:24 PM3/8/03

to

The newer versions are still big-endian.

Paul Bosselaers

Mark A. Odell

unread,

Mar 9, 2003, 11:37:09 AM3/9/03

to

pjb...@attbi.com (Paul J. Bosselaers) wrote in
news:Qovaa.15645$L1.3831@sccrnsc02:

>>> I am porting some code that was originally written for Keil 51
>>> Compiler. There are quite a number of reasonably complex
>>> #defines with unions and structures. Knowing whether the Keil 51
>>> stored data bigger than 8bits as Big- or Little Endian would help.
>>> So i'd appreciate it if someone who has the Keil compiler can give me
>>> the answer.
>>
>>Keil C51 version 5.50 (which I use) and older versions, use big endian.
>>I haven't seen any information from Keil about newer versions that they
>>should have changed that.
>
> The newer versions are still big-endian.

Only the return addresses are stored on the stack little-endian. This is
CPU controlled, not compiler controlled however.

Anton Erasmus

unread,

Mar 12, 2003, 1:53:07 PM3/12/03

to

On Sat, 08 Mar 2003 16:33:38 +0200, Anton Erasmus <ju...@junk.net>
wrote:

Thanks for the replies.

Regarding the apparent posibility that Keil switched from Big to
Little Endian. I would think that any company that does this, will
have quite a few irate customers whos code breaks on the newer
version. I often work on different CPUs that uses either Big- or
Little endian, and so have become sensitised to issues regarding this.
I have found that people who have only programmed on Wintel, often
do not even realise that there are different ways in which multibyte
integers can be stored.
How do most people handle code portability accross endianess ?
I tend to explicitly shift and mask, where an integer has to be a
specific endian.

Regards
Anton Erasmus

Jon Ward

unread,

Mar 12, 2003, 4:56:27 PM3/12/03

to

Keil has not switched from big to little endian.

All 16-bit and 32-bit values are stored, contrary to other Intel processors,
in big endian format--with the high-order byte stored first.

Floating-point numbers are stored according to the IEEE-754 format and are
stored in big endian format with the high-order byte stored first.

Addresses that are PUSHed onto the stack by CALL instructions are stored in
little endian.

Jon Ward
Keil Software

"Anton Erasmus" <ju...@junk.net> wrote in message
news:160v6vs512asa2r89...@4ax.com...