What's the difference between __LITTLE_ENDIAN and __LITTLE_ENDIAN_BITFIELD?
Can someone give me an example when __BIG_ENDIAN and __LITTLE_ENDIAN_BITFIELD
would both be defined simultaneously?
--
Timur Tabi
Linux Kernel Developer @ Freescale
On Oct 5 2007 13:27, Timur Tabi wrote:
>
> What's the difference between __LITTLE_ENDIAN and __LITTLE_ENDIAN_BITFIELD? Can
> someone give me an example when __BIG_ENDIAN and __LITTLE_ENDIAN_BITFIELD would
> both be defined simultaneously?
standard x86:
---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
M765432L M765432L M765432L M765432L [bits] ?_BITFIELD
(Not sure what bitfield type, but I'd guess BIG_ENDIAN_BITFIELD)
standard sparc:
---MSB-- ---3SB-- ---2SB-- ---LSB-- [bytes] BIG_ENDIAN
M765432L M765432L M765432L M765432L [bits] ?_BITFIELD
(I hope I got these two right)
Theoretical machine with BIG_ENDIAN but LITTLE_ENDIAN_BITFIELD:
---MSB-- ---3SB-- ---2SB-- ---LSB--
L234567M L234567M L234567M L234567M
Jan Engelhardt wrote:
> On Oct 5 2007 13:27, Timur Tabi wrote:
>> What's the difference between __LITTLE_ENDIAN and __LITTLE_ENDIAN_BITFIELD? Can
>> someone give me an example when __BIG_ENDIAN and __LITTLE_ENDIAN_BITFIELD would
>> both be defined simultaneously?
>
> standard x86:
> ---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
> M765432L M765432L M765432L M765432L [bits] ?_BITFIELD
>
> (Not sure what bitfield type, but I'd guess BIG_ENDIAN_BITFIELD)
Are you sure? I would think that all machines would have the same byte and
bit endian, otherwise you'd never be able to put a 16-bit value into a shift
register. Your bits will be shifted out like this:
<-- 07 06 05 04 03 02 01 00 15 14 13 12 11 10 09 08
So I think x86 is:
---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
L234567M L234567M L234567M L234567M [bits] LITTLE_ENDIAN_BITFIELD
--
Timur Tabi
Linux Kernel Developer @ Freescale
On Oct 5 2007 14:35, Timur Tabi wrote:
>>
>> standard x86:
>> ---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
>> M765432L M765432L M765432L M765432L [bits] ?_BITFIELD
>>
>> (Not sure what bitfield type, but I'd guess BIG_ENDIAN_BITFIELD)
>
> Are you sure? I would think that all machines would have the same byte and bit
> endian, otherwise you'd never be able to put a 16-bit value into a shift
> register. Your bits will be shifted out like this:
Bit representation is left to the CPU, so 1 << 1 will always be 2,
regardless of whether the byte, when sent out to the network,
is 01000000 or 00000010. Endianess becomes important as soon
as the packet is on the network, of course.
Jan Engelhardt wrote:
> Bit representation is left to the CPU, so 1 << 1 will always be 2,
> regardless of whether the byte, when sent out to the network,
> is 01000000 or 00000010. Endianess becomes important as soon
> as the packet is on the network, of course.
Well yes, that's why I'm asking. I'm not concerned about data from just the
CPU's perspective.
I'm writing a driver that talks to hardware that has a shift register. The
register can be shifted either left or right, so all the bits obviously have
to be in order, but it can be either order.
What I want to do is to have the driver detect when byte-endianness doesn't
match bit-endianness when it writes the the word to a memory-mapped device. I
think I can do that like this:
#if (defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN_BITFIELD)) ||
(defined(BIG_ENDIAN) && defined(LITTLE_ENDIAN_BITFIELD))
#error "This CPU architecture is not supported"
#endif
--
Timur Tabi
Linux Kernel Developer @ Freescale
Timur Tabi <[email protected]> writes:
> I'm writing a driver that talks to hardware that has a shift register.
> The register can be shifted either left or right, so all the bits
> obviously have to be in order, but it can be either order.
Bit addressing is strictly internal to the cpu, the smallest unit that
the cpu can address externally is a byte. The only place where bit
order matters on the C level is in a bitfield that is overlayed over a
block of memory, but this is not visible outside the cpu.
> What I want to do is to have the driver detect when byte-endianness
> doesn't match bit-endianness when it writes the the word to a
> memory-mapped device.
The bit mapping on your device is strictly internal to the device and
has nothing to do with bit order on the C level.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab wrote:
> The bit mapping on your device is strictly internal to the device and
> has nothing to do with bit order on the C level.
Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD. What
does it mean for a C-level bitfield ordering to be little-endian if the
processor is BIG_ENDIAN?
--
Timur Tabi
Linux Kernel Developer @ Freescale
On Fri, 5 Oct 2007, Timur Tabi wrote:
> Andreas Schwab wrote:
>
>> The bit mapping on your device is strictly internal to the device and
>> has nothing to do with bit order on the C level.
>
> Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD.
What does it mean for a C-level bitfield ordering to be little-endian if the
processor is BIG_ENDIAN?
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> -
It makes no sense because a bitfield is something having to
do with a 'C' compiler and it must NEVER be used as a template
to address hardware! 'C' gives no guarantee of the ordering
within machine words. The only way you can access them is
using 'C'. They don't have addresses like other objects
(of course they do exist --somewhere). They are put into
"storage units," according to the standard, and these
storage units are otherwise undefined although you can
align them (don't go there).
If you want to call machine-control bits by name, just
define them as hexadecimal numbers (unsigned ints) and,
if your hardware is for both little/big endian, use
a macro that resolves the issue between the number
and the hardware.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
linux-os (Dick Johnson) wrote:
> It makes no sense because a bitfield is something having to
> do with a 'C' compiler and it must NEVER be used as a template
> to address hardware! 'C' gives no guarantee of the ordering
> within machine words. The only way you can access them is
> using 'C'. They don't have addresses like other objects
> (of course they do exist --somewhere). They are put into
> "storage units," according to the standard, and these
> storage units are otherwise undefined although you can
> align them (don't go there).
Well, if it doesn't make any sense why do we have __LITTLE_ENDIAN_BITFIELD and
__BIG_ENDIAN_BITFIELD? That is, why do we do this:
#if defined(__BIG_ENDIAN_BITFIELD)
__u8 reserved1 : 2;
__u8 ili : 1;
__u8 reserved2 : 1;
__u8 sense_key : 4;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
__u8 sense_key : 4;
__u8 reserved2 : 1;
__u8 ili : 1;
__u8 reserved1 : 2;
#endif
when we can just do this:
#if defined(__BIG_ENDIAN)
__u8 reserved1 : 2;
__u8 ili : 1;
__u8 reserved2 : 1;
__u8 sense_key : 4;
#elif defined(__LITTLE_ENDIAN)
__u8 sense_key : 4;
__u8 reserved2 : 1;
__u8 ili : 1;
__u8 reserved1 : 2;
#endif
> If you want to call machine-control bits by name, just
> define them as hexadecimal numbers (unsigned ints) and,
> if your hardware is for both little/big endian, use
> a macro that resolves the issue between the number
> and the hardware.
That wasn't my intention. I was hoping that __LITTLE_ENDIAN_BITFIELD could be
used to test bit-endianness, but I guess it can't.
--
Timur Tabi
Linux Kernel Developer @ Freescale
On 5 Oct 2007, at 20:35, Timur Tabi wrote:
> Jan Engelhardt wrote:
>> On Oct 5 2007 13:27, Timur Tabi wrote:
>>> What's the difference between __LITTLE_ENDIAN and
>>> __LITTLE_ENDIAN_BITFIELD? Can
>>> someone give me an example when __BIG_ENDIAN and
>>> __LITTLE_ENDIAN_BITFIELD would
>>> both be defined simultaneously?
>> standard x86:
>> ---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
>> M765432L M765432L M765432L M765432L [bits] ?_BITFIELD
>> (Not sure what bitfield type, but I'd guess BIG_ENDIAN_BITFIELD)
>
> Are you sure? I would think that all machines would have the same
> byte and bit endian, otherwise you'd never be able to put a 16-bit
> value into a shift register. Your bits will be shifted out like this:
>
> <-- 07 06 05 04 03 02 01 00 15 14 13 12 11 10 09 08
>
> So I think x86 is:
>
> ---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
> L234567M L234567M L234567M L234567M [bits] LITTLE_ENDIAN_BITFIELD
No it is not. That makes no sense. The whole point of little endian
is that you store LSB, then 2SB, then 3SB, then MSB and then when the
CPU reads this as a 32-bit word it rotates them all around so that in
the CPU register you have:
MSB_3SB_2SB_LSB
M765432L_M765432L_M765432L_M765432L
That is what little endian means and that is how shift operations can
work fine on the CPU.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
Anton Altaparmakov wrote:
>> ---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
>> L234567M L234567M L234567M L234567M [bits] LITTLE_ENDIAN_BITFIELD
>
> No it is not. That makes no sense.
Why not? I honestly don't know what x86 does, but I would think that if I
write a 32-bit value to a memory location, that when I examine that memory
location, all 32 bits will be in order.
> The whole point of little endian is
> that you store LSB, then 2SB, then 3SB, then MSB and then when the CPU
You're talking about byte endian. I'm talking about bit endian -- the order
of bits within a byte. Software cannot know what the bit endian is, but
external devices that have memory-mapped registers can know.
> reads this as a 32-bit word it rotates them all around so that in the
> CPU register you have:
>
> MSB_3SB_2SB_LSB
> M765432L_M765432L_M765432L_M765432L
>
> That is what little endian means and that is how shift operations can
> work fine on the CPU.
The CPU shift operation, yes. I'm talking about shift operations on external
memory-mapped devices.
--
Timur Tabi
Linux Kernel Developer @ Freescale
Timur Tabi <[email protected]> writes:
> Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD.
> What does it mean for a C-level bitfield ordering to be little-endian if
> the processor is BIG_ENDIAN?
Byte endianess and bit endianness are orthogonal concecpts. A cpu can
have insns using both little and big endian bit addressing (btst
vs. bftst on m68k). The bitfield ordering is a property of the ABI and
may even be different from how the cpu numbers the bits in its ISA.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Timur Tabi <[email protected]> writes:
> The CPU shift operation, yes. I'm talking about shift operations on
> external memory-mapped devices.
That is a property of how the device is wired to the bus. The cpu will
always put a value of 128 on the bus such that D7 = 1 and D0-D6 = 0.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab wrote:
> Timur Tabi <[email protected]> writes:
>
>> The CPU shift operation, yes. I'm talking about shift operations on
>> external memory-mapped devices.
>
> That is a property of how the device is wired to the bus. The cpu will
> always put a value of 128 on the bus such that D7 = 1 and D0-D6 = 0.
Yes, but is D7 on the left or on the right?
Anyway, this is academic now. I now know that __LITTLE_ENDIAN_BITFIELD is not
what I want, and that there's no macro that will tell how the lines from the
CPU to external memory are mapped.
--
Timur Tabi
Linux Kernel Developer @ Freescale
Timur Tabi <[email protected]> writes:
> Andreas Schwab wrote:
>> Timur Tabi <[email protected]> writes:
>>
>>> The CPU shift operation, yes. I'm talking about shift operations on
>>> external memory-mapped devices.
>>
>> That is a property of how the device is wired to the bus. The cpu will
>> always put a value of 128 on the bus such that D7 = 1 and D0-D6 = 0.
>
> Yes, but is D7 on the left or on the right?
On the bus there is no left or right. There is only D7 and D0.
> that there's no macro that will tell how the lines from the CPU to
> external memory are mapped.
This is always the same.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Fri, 2007-10-05 at 15:37 -0500, Timur Tabi wrote:
> linux-os (Dick Johnson) wrote:
>
> > It makes no sense because a bitfield is something having to
> > do with a 'C' compiler and it must NEVER be used as a template
> > to address hardware! 'C' gives no guarantee of the ordering
> > within machine words. The only way you can access them is
> > using 'C'. They don't have addresses like other objects
> > (of course they do exist --somewhere). They are put into
> > "storage units," according to the standard, and these
> > storage units are otherwise undefined although you can
> > align them (don't go there).
>
> Well, if it doesn't make any sense why do we have __LITTLE_ENDIAN_BITFIELD and
> __BIG_ENDIAN_BITFIELD? That is, why do we do this:
.../... (snipped horror use of bitfields)
Bitfields are wrong. Period. Don't use them.
__LITTLE_ENDIAN_BITFIELD vs. __BIG_ENDIAN_BITFIELD is Linux way to cope
with existing code using them that needs fixing on architectures that
have C bitfields in reverse order but that's not even something that can
be properly relied upon generally.
Just don't use bitfields and be happy.
Ben.
On Fri, Oct 05, 2007 at 04:10:26PM -0500, Timur Tabi wrote:
> Why not? I honestly don't know what x86 does, but I would think that if I
> write a 32-bit value to a memory location, that when I examine that memory
> location, all 32 bits will be in order.
>
> You're talking about byte endian. I'm talking about bit endian -- the
> order of bits within a byte. Software cannot know what the bit endian is,
> but external devices that have memory-mapped registers can know.
The guy wiring up the hardware should connect the wires correctly.
> The CPU shift operation, yes. I'm talking about shift operations on
> external memory-mapped devices.
Doesn't the bus usually have some definition of bit order which the
device would have to adhere to? After all there must be address lines
somewhere.
Does this perhaps offer anything useful?
http://www.linuxjournal.com/article/6788
--
Len Sorensen
Lennart Sorensen wrote:
>> You're talking about byte endian. I'm talking about bit endian -- the
>> order of bits within a byte. Software cannot know what the bit endian is,
>> but external devices that have memory-mapped registers can know.
>
> The guy wiring up the hardware should connect the wires correctly.
I'm sure they're correct, my problem is that how can my driver know what they are?
> Doesn't the bus usually have some definition of bit order which the
> device would have to adhere to? After all there must be address lines
> somewhere.
I was hoping that there would be some compile-time constant I could check that
would give me this information.
> Does this perhaps offer anything useful?
> http://www.linuxjournal.com/article/6788
Yeah, I read that article some time ago when trying to diagnose the problem I
was seeing. It does explain the point I'm trying to make. We have a device
that's used on two product lines: one ARM-based, and one PowerPC. The ARM is
little-endian, and the PowerPC is big-endian. The device can support
little-endian or big-endian data, as long as the bit-order matches the byte-order.
For now, I'm going to have to assume that they do match.
--
Timur Tabi
Linux Kernel Developer @ Freescale
On Tue, Oct 09, 2007 at 12:56:37PM -0500, Timur Tabi wrote:
> I'm sure they're correct, my problem is that how can my driver know what
> they are?
If they are correct, then you should only need to know about byte order
in my experience.
> I was hoping that there would be some compile-time constant I could check
> that would give me this information.
>
> Yeah, I read that article some time ago when trying to diagnose the problem
> I was seeing. It does explain the point I'm trying to make. We have a
> device that's used on two product lines: one ARM-based, and one PowerPC.
> The ARM is little-endian, and the PowerPC is big-endian. The device can
> support little-endian or big-endian data, as long as the bit-order matches
> the byte-order.
>
> For now, I'm going to have to assume that they do match.
Well that is certainly the normal way it is done. I think a few odd
machines had options for doing different bit orders, but the normal
setup is that it matches since that is the simplest layout when trying
to implement bit shifts in hardware.
--
Len Sorensen
Timur Tabi <[email protected]> writes:
> Yeah, I read that article some time ago when trying to diagnose the
> problem I was seeing. It does explain the point I'm trying to make.
> We have a device that's used on two product lines: one ARM-based, and
> one PowerPC. The ARM is little-endian, and the PowerPC is big-endian.
> The device can support little-endian or big-endian data, as long as
> the bit-order matches the byte-order.
There is no such thing as bit-order. The data lines are numbered,
say, D0 - D31, with D0 being LSB (bit) and D31 MSB.
You usually write register bits from MSB to LSB, so shift left
increments and shift right decrements the value. This is orthogonal
to the big/little-endianness.
Now your device can be connected straight to the bus or the data
lanes (4 on 32-bit PCI) can be crossed. This is platform-dependent.
The kernel provides functions/macros to access devices in
a independent way, such as writel/readl/pci_map_* etc.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> 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)
--
Timur Tabi
Linux Kernel Developer @ Freescale
Krzysztof Halasa wrote:
> There is no such thing as bit-order. The data lines are numbered,
> say, D0 - D31, with D0 being LSB (bit) and D31 MSB.
>
Uh-huh. Check out an IBM Power manual some time.
J
Timur Tabi <[email protected]> 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
Jeremy Fitzhardinge <[email protected]> writes:
>> There is no such thing as bit-order. The data lines are numbered,
>> say, D0 - D31, with D0 being LSB (bit) and D31 MSB.
>>
>
> Uh-huh. Check out an IBM Power manual some time.
Some pointer maybe?
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Timur Tabi <[email protected]> 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 think when the PowerPC is running in little-endian mode, that might be the
case. It needs to be able to write a byte in big-endian mode, and then read
that byte back in little-endian mode and have it be the same byte.
--
Timur Tabi
Linux Kernel Developer @ Freescale
Krzysztof Halasa wrote:
> Some pointer maybe?
>
Erm, a bit of googling will turn one up, but the gist is that IBM has
traditionally bit 0 for MSB and x for LSB. It's a pain to work with:
for one, bits in the same place in a word (say, control register) are
renumbered in 32 vs 64. And I've worked on at least one piece of
hardware in which the hardware designer had a brain-fart and first board
had bit 0 on the CPU wired to bit 0 on the northbridge - should have
been 31 -> 0, 30 -> 1, etc...
J
Timur Tabi <[email protected]> writes:
> I think when the PowerPC is running in little-endian mode, that might
> be the case. It needs to be able to write a byte in big-endian mode,
> and then read that byte back in little-endian mode and have it be the
> same byte.
But this is exactly what excludes changing bit orders :-)
There are other CPU types which can work both LE and BE.
If you write 0x12345678 and switch endianness you get 0x78563412,
but the individual bits are still in the same (natural) order.
In the kernel, to convert from BE to LE or vice versa you need
something like swab32 (assuming 32-bit ints). It doesn't change
the order of the individual bits, it only swaps the (4 in this case)
bytes ("lanes" for hw swapping, PCI etc).
If you, for example, write an 8-bit integer in BE mode and want
it back in LE mode, you have to XOR the address with 0x3, but
the value already comes in the same natural bit order. Of course
swab32 will do as well.
--
Krzysztof Halasa
Jeremy Fitzhardinge <[email protected]> writes:
> but the gist is that IBM has
> traditionally bit 0 for MSB and x for LSB. It's a pain to work with:
> for one, bits in the same place in a word (say, control register) are
> renumbered in 32 vs 64.
I wasn't aware of that, but it doesn't really change the bit order,
only bit names (numbers actually). Extremely weird BTW but I guess
these things weren't that obvious to everyone some 50 years ago.
> And I've worked on at least one piece of
> hardware in which the hardware designer had a brain-fart and first board
> had bit 0 on the CPU wired to bit 0 on the northbridge - should have
> been 31 -> 0, 30 -> 1, etc...
I suspect the board wasn't able to run any OS, was it? :-)
Would make a real example of the different order of bits, though.
--
Krzysztof Halasa
On Tue, 9 Oct 2007, Krzysztof Halasa wrote:
> Jeremy Fitzhardinge <[email protected]> writes:
>
>> but the gist is that IBM has
>> traditionally bit 0 for MSB and x for LSB. It's a pain to work with:
>> for one, bits in the same place in a word (say, control register) are
>> renumbered in 32 vs 64.
>
> I wasn't aware of that, but it doesn't really change the bit order,
> only bit names (numbers actually). Extremely weird BTW but I guess
> these things weren't that obvious to everyone some 50 years ago.
>
>> And I've worked on at least one piece of
>> hardware in which the hardware designer had a brain-fart and first board
>> had bit 0 on the CPU wired to bit 0 on the northbridge - should have
>> been 31 -> 0, 30 -> 1, etc...
>
> I suspect the board wasn't able to run any OS, was it? :-)
> Would make a real example of the different order of bits, though.
> --
> Krzysztof Halasa
> -
There are several chips in which bit 0 is the MSB. For instance,
a National Instruments chip used to interface with a GPIB bus,
TNT--something.
Nevertheless, if I write 0x12 to an 8-bit read/write register,
I will read back 0x12, and if I write 0x1234 to an 16-bit
read/write register, I will read back 0x1234. Regardless
of any endian. So, even though the internal 'value' seem
by the chip might not actually be 0x1234, for bit-mapped
registers it doesn't care because you define the function
of each bit.
The only time one would care is if one was setting a
particular value to a divisor of a timer or something
that needed a particular binary value, rather than bits.
In many cases, the value isn't 'pure' anyway. It might
be in BCD or offset-binary or some other perversion
that requires manipulation anyway so, again it is
important --only to the extent the resulting "number"
seen by the chip needs to be correct.
It is instructive to note that RAM is just a bunch
of bits that are uniquely addressable. Often the CPU
can't address one individual bit, but the interface
hardware does and, in particular, modern RAM makes
sure that bits that are adjacent in words are never
adjacent in the physical devices. This is so that
ECC has a chance of working! A nuclear event that
might upset a bit will 'splash' across an area,
upsetting many bits. If they all belonged to the
same few words, the single-bit correction wouldn't
work. The idea in the architecture it to have
nuclear events cause single-bit errors only, so
the bits of a word are never adjacent in physical
space.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.