Reversing bit order in delphi ?

Hello,

I think intel uses most significant bit first ?

However there are some computers which use least significant bit first.

So what would be the fastest way in pure delphi code to reverse the
bits ?

For example:

[intel system, most significant bit first]

Bit order:

  7,  6,  5,  4,  3,  2,  1,  0

128, 64, 32, 16,  8,  4,  2,  1
  0,  1,  1,  0,  1,  1,  0,  1 = 109

Reversing the bits would give:
  1,  0,  1,  1,  0,  1,  1,  0 = 182

[ibm system or something else, least significant bit first]

Bit order:

  0,  1,  2,  3,  4,  5,  6,  7

  1,  2,  4,  8, 16, 32, 64,128
  0,  1,  1,  0,  1,  1,  0,  1 = 182

Reversing the bits would give:
  1,  0,  1,  1,  0,  1,  1,  0 = 109

Reversing the bits in delphi code might be too slow, if that's the case
is there a special (intel/amd) assembler instruction which might do the
trick ?

Note:

This message is cross posted to:

alt.comp.lang.borland-delphi, alt.lang.asm, comp.lang.asm.x86

Bye,
  Skybuck.

In article <1155977735.677648.69600@m79g2000cwm.googlegroups.com>, 
spamtrap@crayne.org says...
> Reversing bit order in delphi ?
> 
> Hello,
> 
> I think intel uses most significant bit first ?

No -- Intel uses "little-endian", which puts the least significant bits 
first.
 
> However there are some computers which use least significant bit first.

There are also big-endian computers.

> So what would be the fastest way in pure delphi code to reverse the
> bits ?

If you don't want an assembly language version, you shouldn't post to 
assembly language newsgroups. In assembly, I'd probably use:

; input in ebx
; output in ebx
;
	bswap ebx
	mov bl, table[bl]
	ror ebx, 8
	mov bl, table[bl]
	ror ebx, 8
	mov bl, table[bl]
	ror ebx, 8
	mov bl, table[bl]
	ror ebx, 8

where 'table' would be a table of 256 values, each the bit-swapped 
version of a little-endian byte:

table db 000h, 080h, 040h, 0C0h 			; etc.

Of course a great deal depends on whether you want to optimzed for speed 
speed or size. If you want to optimize for speed, you could use a 65536 
word table and convert the dword in two chunks instead of four. If you 
want to optimize for minimum size, you could do something like this:

; input in ebx
; output in eax
; destroys ecx
	mov ecx, 32
loop_top:
	ror ebx, 1
	rcl eax, 1
	loop loop_top

Of course, it can also depend on how much data you're going to convert 
at a time. The table-driven versions use memory, so for any kind of real 
speed, they depend on the table being in the cache. When it's not in the 
cache, it's going to take quite a while to retrieve that data. These 
versions are slow the first few times you use them, but if you convert a 
big buffer in a tight loop (for example) they'll speed up considerably 
once the entire table is in the cache.

The loop version requires 32 iterations, but doesn't require any 
external data, so its speed remains nearly constant regardless of usage.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

"Skybuck" <spamtrap@crayne.org> schrieb im Newsbeitrag
news:1155977735.677648.69600@m79g2000cwm.googlegroups.com...
> I think intel uses most significant bit first ?
> However there are some computers which use least significant bit first.

No, there are no such CPU manufacturers.

You are confusing this with the 'Little Endian' and 'Big Endian'
representation in RAM, which has nothing to do with bits in bytes, but with
bytes in words/doublewords etc. http://wikipedia.org does tell you about the
difference.

To swap the 4 bytes in a 32-bit unit, use following algrorithm, given in
pseudocode for whatever language (provided that rotates (ROL and ROR) are
supported in your programming language):

A = B                   [aabbccdd]
A leftrotate 8 bit      [bbccddaa]
B rightrotate 8 bit     [ddaabbcc]
A and 00ff00ff          [--cc--aa]
B and ff00ff00          [dd--bb--]
A or B                  [ddccbbaa]

Regards
//Herbert Glarner

Skybuck wrote:

> Reversing bit order in delphi ?
> 
> Hello,
> 
> I think intel uses most significant bit first ?
> 
> However there are some computers which use least significant bit first.
> 
> So what would be the fastest way in pure delphi code to reverse the
> bits ?
> 
> For example:
> 
> [intel system, most significant bit first]
> 
> Bit order:
> 
>   7,  6,  5,  4,  3,  2,  1,  0
> 
> 128, 64, 32, 16,  8,  4,  2,  1
>   0,  1,  1,  0,  1,  1,  0,  1 = 109
> 
> Reversing the bits would give:
>   1,  0,  1,  1,  0,  1,  1,  0 = 182
> 
> [ibm system or something else, least significant bit first]
> 
> Bit order:
> 
>   0,  1,  2,  3,  4,  5,  6,  7
> 
>   1,  2,  4,  8, 16, 32, 64,128
>   0,  1,  1,  0,  1,  1,  0,  1 = 182
> 
> Reversing the bits would give:
>   1,  0,  1,  1,  0,  1,  1,  0 = 109
> 
> Reversing the bits in delphi code might be too slow, if that's the case
> is there a special (intel/amd) assembler instruction which might do the
> trick ?
> 
> Note:
> 
> This message is cross posted to:
> 
> alt.comp.lang.borland-delphi, alt.lang.asm, comp.lang.asm.x86
> 
> Bye,
>   Skybuck.
> 
With todays computers - - why not step back and take a different look at 
the problem

   Simply generate a table of values from $FF down to 0

then

      Swapedbyte = SwapTable[Byte_Value];

This is only a table of 256 bytes. - - - and it is fast as you can see.

I have not looked at the timing for a loop that would process millions 
of bytes - - but I would expect this to be able to do 10's or 100's of 
millions of byte swaps a second.

as you are always one to argue about speed and performance - -

and most likely are going to complain about the 256 bytes needed for the 
table - on a machine that has 100's of millions of bytes of memory - - -
and a blotted OS - - and the table is only going to be a small part of 
the code - - - so who cares about 256 bytes in a program that is going 
to be 100's of K in size or in the meg range.

Jim P.

Regardless of how data is stored in memory, on the power pc once data
is in a register the bit numbering system is reversed from that of x86.
 The most significant bit is considered bit 0.

Bit me in the butt at work when writing ada/c bindings for packed data
structures.


Herbert Glarner wrote:
> "Skybuck" <spamtrap@crayne.org> schrieb im Newsbeitrag
> news:1155977735.677648.69600@m79g2000cwm.googlegroups.com...
> > I think intel uses most significant bit first ?
> > However there are some computers which use least significant bit first.
>
> No, there are no such CPU manufacturers.
>
> You are confusing this with the 'Little Endian' and 'Big Endian'
> representation in RAM, which has nothing to do with bits in bytes, but with
> bytes in words/doublewords etc. http://wikipedia.org does tell you about the
> difference.
>
> To swap the 4 bytes in a 32-bit unit, use following algrorithm, given in
> pseudocode for whatever language (provided that rotates (ROL and ROR) are
> supported in your programming language):
>
> A = B                   [aabbccdd]
> A leftrotate 8 bit      [bbccddaa]
> B rightrotate 8 bit     [ddaabbcc]
> A and 00ff00ff          [--cc--aa]
> B and ff00ff00          [dd--bb--]
> A or B                  [ddccbbaa]
> 
> Regards
> //Herbert Glarner

> With todays computers - - why not step back and take a different look at
> the problem
>
>    Simply generate a table of values from $FF down to 0

How do you generate the table ? ;)

Hint:

It's not as trivial as one might think ;)

>
> then
>
>       Swapedbyte = SwapTable[Byte_Value];
>
> This is only a table of 256 bytes. - - - and it is fast as you can see.

Yes.

Bye,
  Skybuck.

Herbert Glarner schreef:

> "Skybuck" <spamtrap@crayne.org> schrieb im Newsbeitrag
> news:1155977735.677648.69600@m79g2000cwm.googlegroups.com...
> > I think intel uses most significant bit first ?
> > However there are some computers which use least significant bit first.
>
> No, there are no such CPU manufacturers.
>
> You are confusing this with the 'Little Endian' and 'Big Endian'
> representation in RAM, which has nothing to do with bits in bytes, but with
> bytes in words/doublewords etc. http://wikipedia.org does tell you about the
> difference.
>
> To swap the 4 bytes in a 32-bit unit, use following algrorithm, given in
> pseudocode for whatever language (provided that rotates (ROL and ROR) are
> supported in your programming language):
>
> A = B                   [aabbccdd]
> A leftrotate 8 bit      [bbccddaa]
> B rightrotate 8 bit     [ddaabbcc]
> A and 00ff00ff          [--cc--aa]
> B and ff00ff00          [dd--bb--]
> A or B                  [ddccbbaa]

Thank you for this explanation how to "rotate" and "and" the bytes back
together in reversed order, I am sure the same technique can be applied
to bits.

However you are probably wrong, there are cpu's with different bit
order.

In any case I want to write some software which is "feature/future"
proof, it should be able to read binary fields/files no matter the
binary format.

Bye,
  Skybuck.

On Sat, 19 Aug 2006 14:17:15 -0600, Jerry Coffin
<spamtrap@crayne.org> wrote:

>In article <1155977735.677648.69600@m79g2000cwm.googlegroups.com>, 
>spamtrap@crayne.org says...
>> Reversing bit order in delphi ?
>> 
>> Hello,
>> 
>> I think intel uses most significant bit first ?

>No -- Intel uses "little-endian", which puts the least significant bits 
>first.

It does use Little-endian, but that is more to do with the order of
bytes in say a Word   [ Lo ]  [ Hi ]

Consider   SHL, 1   to multiply by 2

01000000b   -->  10000000b     ( unsigned  64  --> 128 )

Skybuck schreef:

> Woops, sorry, I did not know comp.lang.asm.x86 is a moderated
> newsgroup, as I don't like moderated newsgroups I post it again and
> exclude comp.lang.asm.x86:
>
> Reversing bit order in delphi ?
>
> Hello,
>
> I think intel uses most significant bit first ?

Nope, sorry, I was wrong.

The byte order and bit order of data in RAM is both Little Endian for
intel. (LSB)

The byte order and bit order of CPU registers is both Little Endian for
intel. (LSB)

The drawing below was correct, but the comments are wrong.

When transmitting bits and bytes intels reads from right to left.

So intel starts reading at the lowest bit order/number.

So that means least significant data bit/byte first.

> [intel system, most significant bit first]

Should be:

[intel system, lest significant bit (and byte) first]

Bye,
  Skybuck.

In article <44e82846.265184268@news.btopenworld.com>, 
spamtrap@crayne.org says...
> On Sat, 19 Aug 2006 14:17:15 -0600, Jerry Coffin
> <spamtrap@crayne.org> wrote:
> 
> >In article <1155977735.677648.69600@m79g2000cwm.googlegroups.com>, 
> >spamtrap@crayne.org says...
> >> Reversing bit order in delphi ?
> >> 
> >> Hello,
> >> 
> >> I think intel uses most significant bit first ?
> 
> >No -- Intel uses "little-endian", which puts the least significant bits 
> >first.
> 
> It does use Little-endian, but that is more to do with the order of
> bytes in say a Word   [ Lo ]  [ Hi ]
> 
> Consider   SHL, 1   to multiply by 2
> 
> 01000000b   -->  10000000b     ( unsigned  64  --> 128 )

More accurately, the order of bytes is what's visible. The bits 
obviously have to have a particular order within a byte as well, but at 
the software level that's not really visible because you can't address 
the individual bits -- you have to retrieve a whole byte (at a minimum).

Nonetheless, the ordering does exist -- if (for example) you design 
hardware in something like Verilog or VHDL, the ordering becomes quite 
apparent. For example, to describe an OR gate on a little-endian design, 
you'd have something like this:

-- VHDL
entity or_gate is 
	port(a: in std_logic(31 downto 0), 
	     b: in std_logic(31 downto 0),
	     c: out std_logic(31 downto 0));
end entity or_gate;

Whereas the same or-gate in a big-endian design would look like this:

entity or_gate is 
	port(a: in std_logic(0 to 31), 
	     b: in std_logic(0 to 31),
	     c: out std_logic(0 to 31));
end entity or_gate;

/* Verilog, little-endian */
module or_gate(a, b, c);
	input [31:0] a;
	input [31:0] b;
	output [31:0] c;

Whereas a big-endian design would look like:

module or_gate(a, b, c);
	input [0:31] a;
	input [0:31] b;
	output [0:31] c;

Of course, these are incomplete -- these just describe the inputs and 
outputs, rather than including the implementation (though the 
implementation of an or-gate is obviously trivial).

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Skybuck wrote:
>>With todays computers - - why not step back and take a different look at
>>the problem
>>
>>   Simply generate a table of values from $FF down to 0
> 
> 
> How do you generate the table ? ;)
> 
> Hint:
> 
> It's not as trivial as one might think ;)
> 
> 
>>then
>>
>>      Swapedbyte = SwapTable[Byte_Value];
>>
>>This is only a table of 256 bytes. - - - and it is fast as you can see.
> 
> 
> Yes.
> 
> Bye,
>   Skybuck.
> 
are you that dense.  You can generate the table in source code
or simply create it as an array and then fill the table in at run time.

So what is the problem - - the only time that I would be concerned about
which way was the best is if the code did this lots of times.

Jim P.

"Samuel  Stearley"  <spamtrap@crayne.org> wrote:
>
>Regardless of how data is stored in memory, on the power pc once data
>is in a register the bit numbering system is reversed from that of x86.
> The most significant bit is considered bit 0.

That's a documentation issue, not a programming issue.

>Bit me in the butt at work when writing ada/c bindings for packed data
>structures.

Quite possible, but that is completely unrelated to the hardware.  The
order of bitfields in a C struct is entirely up to the compiler.  Even two
compilers on the same processor can use different bit ordering for a
bitfield struct.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

"Skybuck"  <spamtrap@crayne.org> wrote:
>
>Herbert Glarner schreef:
>
>> "Skybuck" <spamtrap@crayne.org> schrieb:
>>
>> > I think intel uses most significant bit first ?
>> > However there are some computers which use least significant bit first.
>>
>> No, there are no such CPU manufacturers.
>>
>> You are confusing this with the 'Little Endian' and 'Big Endian'
>> representation in RAM, which has nothing to do with bits in bytes, but with
>> bytes in words/doublewords etc. http://wikipedia.org does tell you about the
>> difference.
>
>Thank you for this explanation how to "rotate" and "and" the bytes back
>together in reversed order, I am sure the same technique can be applied
>to bits.
>
>However you are probably wrong, there are cpu's with different bit
>order.

No.  Herbert is correct -- you are misunderstanding the terms.

Consider an 8-bit register, containing the decimal value 97.  I will label
the bits with neutral letters to avoid confusion:

     I   J   K   L   M   N   O   P
   +---+---+---+---+---+---+---+---+
   | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 |
   +---+---+---+---+---+---+---+---+

In that diagram, the bit labelled "I" is the most significant bit, and the
bit labelled "P" is the least significant bit.  That labelling will always
be true, regardless of the processor or architecture.

Now, with some processors, the bit labelled I is called "bit 0", and in
other processors, the bit labelled I is called "bit 7".  However, that is
strictly a documentation issue.  It is completely irrelevant when you are
programming.

>In any case I want to write some software which is "feature/future"
>proof, it should be able to read binary fields/files no matter the
>binary format.

That is impossible in the general case.  Now, if this is data that YOU are
generating, then you can specify exactly what format it is stored in.  For
example, the TCP/IP protocols specify that, on the network itself, the
least significant BYTES come first (big-endian).  That means that programs
on an Intel processor have to swap the bytes before using them.

But if you don't know the exact format beforehand, you cannot possibly
create a pure, machine-independent reader for them.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

"Skybuck"  <spamtrap@crayne.org> wrote:
>
>Nope, sorry, I was wrong.
>
>The byte order and bit order of data in RAM is both Little Endian for
>intel. (LSB)
>
>The byte order and bit order of CPU registers is both Little Endian for
>intel. (LSB)

You are still missing the point here.  There is no such thing as "bit
order", because bits in an Intel system are never transmitted serially.  A
byte is always treated as a complete unit, so bit ordering means nothing.

>When transmitting bits and bytes intels reads from right to left.

No.  Intel processors never transmit "bits".

>So intel starts reading at the lowest bit order/number.
>
>So that means least significant data bit/byte first.
>
>> [intel system, most significant bit first]
>
>Should be:
>
>[intel system, lest significant bit (and byte) first]

I'm not sure what point you are trying to make.  What does "first" mean
here?  Yes, if you store a 4-byte value in memory on an Intel processor,
the least-significant byte will be stored at the lowest byte address.  But
what does "least significant bit first" mean?  If "first" means "left to
right", as with the bytes, then Intel processors are "most significant bit
first", as are most processors.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

>>For example, the TCP/IP protocols specify that, on the network itself, the least significant BYTES come first (big-endian).

Putting the least significant bytes first is little endian.

http://www.webopedia.com/TERM/b/big_endian.html


Tim Roberts wrote:
> "Skybuck"  <spamtrap@crayne.org> wrote:
> >
> >Herbert Glarner schreef:
> >
> >> "Skybuck" <spamtrap@crayne.org> schrieb:
> >>
> >> > I think intel uses most significant bit first ?
> >> > However there are some computers which use least significant bit first.
> >>
> >> No, there are no such CPU manufacturers.
> >>
> >> You are confusing this with the 'Little Endian' and 'Big Endian'
> >> representation in RAM, which has nothing to do with bits in bytes, but with
> >> bytes in words/doublewords etc. http://wikipedia.org does tell you about the
> >> difference.
> >
> >Thank you for this explanation how to "rotate" and "and" the bytes back
> >together in reversed order, I am sure the same technique can be applied
> >to bits.
> >
> >However you are probably wrong, there are cpu's with different bit
> >order.
>
> No.  Herbert is correct -- you are misunderstanding the terms.
>
> Consider an 8-bit register, containing the decimal value 97.  I will label
> the bits with neutral letters to avoid confusion:
>
>      I   J   K   L   M   N   O   P
>    +---+---+---+---+---+---+---+---+
>    | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 |
>    +---+---+---+---+---+---+---+---+
>
> In that diagram, the bit labelled "I" is the most significant bit, and the
> bit labelled "P" is the least significant bit.  That labelling will always
> be true, regardless of the processor or architecture.
>
> Now, with some processors, the bit labelled I is called "bit 0", and in
> other processors, the bit labelled I is called "bit 7".  However, that is
> strictly a documentation issue.  It is completely irrelevant when you are
> programming.
>
> >In any case I want to write some software which is "feature/future"
> >proof, it should be able to read binary fields/files no matter the
> >binary format.
>
> That is impossible in the general case.  Now, if this is data that YOU are
> generating, then you can specify exactly what format it is stored in.  For
> example, the TCP/IP protocols specify that, on the network itself, the
> least significant BYTES come first (big-endian).  That means that programs
> on an Intel processor have to swap the bytes before using them.
>
> But if you don't know the exact format beforehand, you cannot possibly
> create a pure, machine-independent reader for them.
> -- 
> - Tim Roberts, timr@probo.com
>   Providenza & Boekelheide, Inc.

> Now, with some processors, the bit labelled I is called "bit 0", and in
> other processors, the bit labelled I is called "bit 7".  However, that is
> strictly a documentation issue.  It is completely irrelevant when you are
> programming.

I don't think so.

There are probably instructions where one can write:

Test bit 5

or

Test bit 7

It's relevant.

Bye,
  Skybuck.

Tim Roberts schreef:

> "Skybuck"  <spamtrap@crayne.org> wrote:
> >
> >Nope, sorry, I was wrong.
> >
> >The byte order and bit order of data in RAM is both Little Endian for
> >intel. (LSB)
> >
> >The byte order and bit order of CPU registers is both Little Endian for
> >intel. (LSB)
>
> You are still missing the point here.  There is no such thing as "bit
> order", because bits in an Intel system are never transmitted serially.  A
> byte is always treated as a complete unit, so bit ordering means nothing.
>
> >When transmitting bits and bytes intels reads from right to left.
>
> No.  Intel processors never transmit "bits".

Processor's don't communicate with main memory ?

Wow that's new !

>
> >So intel starts reading at the lowest bit order/number.
> >
> >So that means least significant data bit/byte first.
> >
> >> [intel system, most significant bit first]
> >
> >Should be:
> >
> >[intel system, lest significant bit (and byte) first]
>
> I'm not sure what point you are trying to make.  What does "first" mean
> here?  Yes, if you store a 4-byte value in memory on an Intel processor,
> the least-significant byte will be stored at the lowest byte address.  But
> what does "least significant bit first" mean?  If "first" means "left to
> right", as with the bytes, then Intel processors are "most significant bit
> first", as are most processors.

You might have a point here. Or maybe it's irrelevant, since bits are
transferred in groups called "bytes".

However intel's documentation shows a layout where all arrows point
from right to left, including the arrows in the cpu register.

One would have to examine the hardware layout to figure out if:

1. All bits arrive at the same time.
or
2.The most signicant bits of a byte arrive first.
or
3.The least signicant bits of a byte arrive first.

This might be relevant for hardware manufacturers. For programmers it's
irrelevant.

The bit order is relevant.

When I write instruction: Test bit 5.

Which bit is ment ? 

That's the question.

Bye,
  Skybuck.

Tim Roberts wrote:

> That is impossible in the general case.  Now, if this is data that
> YOU are generating, then you can specify exactly what format it is
> stored in.  For example, the TCP/IP protocols specify that, on the
> network itself, the least significant BYTES come first (big-endian).
> That means that programs on an Intel processor have to swap the bytes
> before using them.

Wouldn't that be *most* significant bytes first, for big-endian?

Tim Roberts wrote:
> "Skybuck"  <spamtrap@crayne.org> wrote:
>> [intel system, lest significant bit (and byte) first]
> 
> I'm not sure what point you are trying to make.  What does "first" mean
> here?  

Some instructions refer to actual bit positions, e.g. "bt" on x86 and
"rlwinm" on PowerPC. And for "bt" bit 0 is the LSB and for "rlwinm" bit
0 is the MSB.

Of course you never actually have to reverse the bit order but just do
(32-bitindex) to convert between these conventions.

-- 
Gru�,
Sebastian

Skybuck wrote:
> Tim Roberts schreef:
> 
>>You are still missing the point here.  There is no such thing as "bit
>>order", because bits in an Intel system are never transmitted serially.  A
>>byte is always treated as a complete unit, so bit ordering means nothing.
>>
>>>When transmitting bits and bytes intels reads from right to left.
>>
>>No.  Intel processors never transmit "bits".
> 
> Processor's don't communicate with main memory ?
> 
> Wow that's new !

x86 processors don't communicate serially with their memories.  Even on 
the lowly 8088, all memory access was at least 8-bit parallel. 
"Endian-ness" only refers to byte ordering and not bit ordering.

>>I'm not sure what point you are trying to make.  What does "first" mean
>>here?  Yes, if you store a 4-byte value in memory on an Intel processor,
>>the least-significant byte will be stored at the lowest byte address.  But
>>what does "least significant bit first" mean?  If "first" means "left to
>>right", as with the bytes, then Intel processors are "most significant bit
>>first", as are most processors.
> 
> You might have a point here. Or maybe it's irrelevant, since bits are
> transferred in groups called "bytes".
> 
> However intel's documentation shows a layout where all arrows point
> from right to left, including the arrows in the cpu register.

It's important to be clear in documentation about which bit is which, 
but in the hardware, there isn't any such thing as bit order until the 
bits are transmitted serially instead of in parallel.

As an analogy, when an commercial airline jet lands, which person in the 
plane lands first?  In normal usage, it's a nonsensical question since 
we consider all of the passengers to be arriving together at the same 
time (i.e. in parallel).  When the passengers leave the plane, there is 
usually only room for one at a time to exit (i.e. serially) so it *does* 
make sense to say that the person from seat 1A arrives in the terminal 
before the person in seat 35A.

Where it is important to identify a particular bit (as in a flags 
register, for example) documentation will make it clear which bit is 
being referred to.  The convention is to number the bits starting from 0 
to indicate the least significant bit, up to 7 or 15 or 31 or 63 or 
whatever the data width happens to be.  You will find that all Intel 
documentation for the x86 processors is consistent in using that convention.

Ed

Tim Roberts  <spamtrap@crayne.org> writes:
> No.  Intel processors never transmit "bits".

But they do _index_ bits.

Phil
-- 
"Home taping is killing big business profits. We left this side blank 
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.

On 23 Aug 2006 01:31:08 +0300, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> wrote:

>"Home taping is killing big business profits. We left this side blank 
>so you can help." -- Dead Kennedys, written upon the B-side of tapes of
>/In God We Trust, Inc./.

It took me a few seconds to understand that
- it is classic

"Samuel  Stearley"  <spamtrap@crayne.org> wrote:

>>>For example, the TCP/IP protocols specify that, on the network itself, the least significant BYTES come first (big-endian).
>
>Putting the least significant bytes first is little endian.
>
>http://www.webopedia.com/TERM/b/big_endian.html

Duh, yes, I knew that.  Sorry.  In TCP/IP, the most significant bytes come
first (big-endian).
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

"Skybuck"  <spamtrap@crayne.org> wrote:
>
>> Now, with some processors, the bit labelled I is called "bit 0", and in
>> other processors, the bit labelled I is called "bit 7".  However, that is
>> strictly a documentation issue.  It is completely irrelevant when you are
>> programming.
>
>I don't think so.
>
>There are probably instructions where one can write:
>
>Test bit 5
>
>or
>
>Test bit 7
>
>It's relevant.

Yes, I concede that point.  However, that only applies in assembler
programming, and an assembler program is always targeted at one particular
processor, where the meaning of "test bit 5" will always be the same.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.