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
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
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
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
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
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
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
-
To unsubscribe from
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,
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
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
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
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
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
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.
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
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
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
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
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
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
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
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
-
To unsubscribe from this list:
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
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
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
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
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
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
>>
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
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.
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
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
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
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
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
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
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
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 0100 or 0010. Endianess becomes important as soon
as the packet is on the network, of course.
Well yes, that's why I'm asking. I'm
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
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--
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--
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
-
To unsubscribe from this list: send the line
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
-
To unsubscribe from this list: send the line
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]
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--
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 0100 or 0010. Endianess becomes important as soon
as the packet is on the network, of course.
Well yes, that's why I'm asking. I'm
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
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
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
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
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
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
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
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
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 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
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
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
58 matches
Mail list logo
