This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: REAL meaning of little-endian and big-endian?



Dear Chris,
thanks a lot for your detailed interpretation !
I am coding a protocol,i hope to get a crossing- platform feature,so I do not want to use bit-fields,so i define my tcp/ip header without bitfileds,but when i receive a packet, how to get ip_version? for i do not know it in first or last in a byte. and other bits,such as ip options bits will involve this problem,too.
so this is a bad matter without nessesary,why not compiler apply a standard bit-field storage way?






From: Chris Gray <chris.gray@acunia.com>
To: 张 亮 <johnsonest@hotmail.com>
CC: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] REAL meaning of little-endian and big-endian?
Date: Tue, 17 Dec 2002 09:58:55 +0100 (CET)

On Tue, 17 Dec 2002, [gb2312] 张 亮 wrote:

>
> hello,every one!
> I have a "old" and "simple" question (i think like this before):
> 1 both endian mode only differ in byte order? how bit-order in
one byte?

If we are talking about data stored in memory, this question is pretty
well meaningless: for most CPUs the smallest amount of data that can be
moved between CPU and memory is a byte, and all 8 bits move at the same
time. So whether you call the most or the least significant bit 'bit 0' is
purely a matter of convention: nowadays everybody calls the least
significant bit 'bit 0', but at one time the US did this and the UK did
the opposite! So an american would say `bit 0' and a brit would say `bit
7', and they would be talking about the same bit ...

If we are talking about how data is transmitted `on the wire', then the
question may or may not be meaningful (think of a parallel cable!), and if
it is then the answer is only really useful if you are monitoring the wire
with an oscilloscope: your software can only see the data as an array of
bytes in memory, individual bits being handled by the hardware UART or MAC
or whatever. I think that most serial communication actually sends the
least significant bit first (and that ISO 3309 calls this 'bit 1'!), but I
may be misremembering.

> 2 if differ in bit order,one byte with little-endian come from
> net,then how me(receiver host with big-endian) to read it correctlly?
from
> IP processing,it simplely read it! why?

See above. Unless you are actually `bit-banging' in software, you never
see the individual bits within a byte. In IP, fields of more than one byte
(e.g. the network address) are _always_ transmitted with the most
significant byte first, regardless of the `endianness' of the CPU
involved. So `host byte ordering' may be big- or little-endian, but
`network byte ordering' is always big-endian.

>     3 if identical in bit order,why so define:
>
> struct ip_hdr
> {
>
> #if BYTE_ORDER ==LITTLE_ENDIAN
>  unsigned char ip_version;4,
>                ip_hlen:4;
> #elif BYTE_ORDER ==BIG_ENDIAN
> unsigned char ip_hlen :4,
>               ip_version:4;
> #endif

Very good question! The C standard doesn't specify the order of bitfields
within a byte or word, so the interpretation is up to the writer of the
compiler. The code you quote has probably been tested with gcc on both
big- and little-endian machines, so I suppose that gcc uses a convention
that bitfields are arranged according to the endianness of the CPU. Other
C compilers may behave differently. (I got badly burned by this some 7 or
8 years ago, and I've never used bitfields since. 8-0 So I neither know
nor care what convention gcc is using ...)

Good luck

--

Chris Gray

VM Architect, ACUNIA

_________________________________________________________________
与联机的朋友进行交流,请使用 MSN Messenger: http://messenger.msn.com/cn

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]