[ECOS] 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