Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Mar 2011 01:09:23 -0800
From:      perryh@pluto.rain.com
To:        ertr1013@student.uu.se
Cc:        frank@solensky.org, freebsd-questions@freebsd.org
Subject:   Re: Bit order == byte order??
Message-ID:  <4d70ac43.iPJOAUhHtgE0uJR%2B%perryh@pluto.rain.com>
In-Reply-To: <20110303205010.GA47653@owl.midgard.homeip.net>
References:  <910E776A-D865-4F78-8BE5-E974326636D0@solensky.org> <20110303205010.GA47653@owl.midgard.homeip.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Erik Trulsson <ertr1013@student.uu.se> wrote:
> On Thu, Mar 03, 2011 at 11:26:12AM -0500, Frank Solensky wrote:
> > In sys/netinet/ip.h, the first octet of the ip header structure
> > tests the byte ordering to determine the ordering of the header
> > length (ip_hl) and version (ip_v) fields.
> > 
> > My question: that always works?  While my reading of the
> > language specification document leaves both the ordering of
> > the bits within a byte and the bytes within a longer field as
> > implementation choices, the two are independent of each other.
> > 
> > I haven't run into a CPU where this assumption was proven
> > incorrect ...
>
> Unless you have a CPU where memory is addressed bit-by-bit rather
> than byte-by-byte the ordering of bits within a byte is not only
> completely irrelevant, it is also pretty much impossible to
> determine programatically.

Agreed it is at least difficult to determine programatically,
however it is quite important when dealing with hardware that
converts between a sequence of bytes and a bitstream, e.g.
serial ports, network interfaces, SATA ports.  Driver writers
had _better_ know which bit of the byte, as well as which
byte of a word/longword/quadword, is going on the wire first.

The O.P. is absolutely correct that bit order within a byte and byte
order within a multibyte field need not, in principle, be the same.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4d70ac43.iPJOAUhHtgE0uJR%2B%perryh>