From: Krzysztof Halasa <khc@pm.waw.pl>
To: Timur Tabi <timur@freescale.com>
Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>,
Anton Altaparmakov <aia21@cam.ac.uk>,
Jan Engelhardt <jengelh@computergmbh.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
Date: Tue, 09 Oct 2007 21:37:52 +0200 [thread overview]
Message-ID: <m37ilwcc4v.fsf@maximus.localdomain> (raw)
In-Reply-To: <470BCEFC.9060302@freescale.com> (Timur Tabi's message of "Tue, 09 Oct 2007 13:57:00 -0500")
Timur Tabi <timur@freescale.com> writes:
>> There is no such thing as bit-order.
>
> Yes, there is. You need to read the article at
> http://www.linuxjournal.com/article/6788. Explains what it means for
> bits to be in one order versus another. This is from the perspective
> of external devices, not the CPU (which is always consistent with
> regards to bit order)
Have you ever seen a device or platform with the bits reversed?
I.e. one on which 0x01 from CPU POV is 0x80 or 0x80000000 etc.
from device's POV?
Perhaps I was too brief, I should've written "there is no such
thing WRT the CPU-device connections" because the bit order
actually exists on things like serial lines, though it's totally
independent from big/little endianness of the CPU and/or
peripheral devices, and one can't assume anything matches there.
On parallel bus, all bits (at least of an 8-bit byte) are stored
and transmitted at the same time and address, so no bit can be
first or last.
Once again, you shift left (towards MSBit), you multiply, shifting
right divides. At least as long as you limit it to a single byte.
Perhaps if you tell us what are you exactly trying to achieve...
--
Krzysztof Halasa
next prev parent reply other threads:[~2007-10-09 19:38 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-05 18:27 __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD Timur Tabi
2007-10-05 18:35 ` Jan Engelhardt
2007-10-05 19:35 ` Timur Tabi
2007-10-05 19:43 ` Jan Engelhardt
2007-10-05 19:47 ` Timur Tabi
2007-10-05 20:04 ` Andreas Schwab
2007-10-05 20:07 ` Timur Tabi
2007-10-05 20:34 ` linux-os (Dick Johnson)
2007-10-05 20:37 ` Timur Tabi
2007-10-05 23:27 ` Benjamin Herrenschmidt
2007-10-05 21:17 ` Andreas Schwab
2007-10-05 21:06 ` Anton Altaparmakov
2007-10-05 21:10 ` Timur Tabi
2007-10-05 21:29 ` Andreas Schwab
2007-10-05 21:32 ` Timur Tabi
2007-10-05 23:17 ` Andreas Schwab
2007-10-09 17:46 ` Lennart Sorensen
2007-10-09 17:56 ` Timur Tabi
2007-10-09 18:34 ` Lennart Sorensen
2007-10-09 18:50 ` Krzysztof Halasa
2007-10-09 18:57 ` Timur Tabi
2007-10-09 19:37 ` Krzysztof Halasa [this message]
2007-10-09 19:44 ` Timur Tabi
2007-10-09 22:11 ` Krzysztof Halasa
2007-10-09 19:11 ` Jeremy Fitzhardinge
2007-10-09 19:39 ` Krzysztof Halasa
2007-10-09 21:40 ` Jeremy Fitzhardinge
2007-10-09 22:34 ` Krzysztof Halasa
2007-10-10 12:05 ` linux-os (Dick Johnson)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m37ilwcc4v.fsf@maximus.localdomain \
--to=khc@pm.waw.pl \
--cc=aia21@cam.ac.uk \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=timur@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox