Lack of bit field instructions in x86 instruction set because of patents ?

  • Thread starter Thread starter Skybuck Flying
  • Start date Start date
S

Skybuck Flying

Hello,

I have a question for you:

Can the lack of bit field instructions in the x86 instruction set be
explained by patents held by other cpu designers like motorola ?

Or is there another reason why x86 instruction set is missing bit field
instructions ?

Bye,
Skybuck.
 
JJ said:
What kind of bit field instruction(s) is lacking?

See motorola processor or nec processor.

InsertBits, ExtractBits, stuff like that ;)

Bye,
Skybuck.
 
Skybuck Flying said:
Hello,

I have a question for you:

Can the lack of bit field instructions in the x86 instruction set be
explained by patents held by other cpu designers like motorola ?

Or is there another reason why x86 instruction set is missing bit field
instructions ?

Bye,
Skybuck.

So that means that BT, BTC, BTR and BTS were not sufficient? Your bitfields
must be larger?
 
Can the lack of bit field instructions in the x86 instruction set be
explained by patents held by other cpu designers like motorola ?

Certainly not, since bit-fields are both obvious and have been implemented
in a variety of machines for the past 50 years or so.
Or is there another reason why x86 instruction set is missing bit field
instructions ?

They aren't worth it. On the few occasions when you need the facility, a
mask and shift takes just two more instructions. (For comparisons or
arithmetic on similar bit-fields, you can even omit the shift step.)
 
See motorola processor or nec processor.

InsertBits, ExtractBits, stuff like that ;)

Bye,
  Skybuck.



Could you please explain why, in your opinion, instructions such as
the following 8 bit instructions as well as the respective 16 and 32
bit do not fit the bill?


OR AL,bbbbbbbbB
AND AL,bbbbbbbbB
XOR AL,bbbbbbbbB
TEST AL,bbbbbbbbB

where "b" represents a zero or one bit.
 
Can the lack of bit field instructions in the x86 instruction set be
explained by patents held by other cpu designers like motorola ?
No

Or is there another reason why x86 instruction set is missing bit field
instructions ?

Barcelona (AMD) introduced 5 (or was it 7) bit manipulation
instructions.

Mitch
 
Here is an example of what a motorola processor presumeably does with one
instruction:

function KeepLowBits( Value : longword; Bits : longword ) : longword;
inline;
begin
Result := Value; // 32 bits case.
if Bits <= 31 then
begin
Result := Result and not (4294967295 shl Bits); // shl instruction limited
to 31.
end;
end;

function ShiftLeft( Left : longword; Right : Longword; Shift : longword ) :
longword;
asm
shld eax, edx, cl
end;

procedure WriteLongwordBits( Value : longword; Bits : longword; DestAddress
: pointer; DestBitIndex : longword );
var
vContent : longword;
vMask : longword;
vShift : longword;

vFirstContent : longword;
vSecondContent : longword;

vFirstMask : longword;
vSecondMask : longword;

vFirstAddress : longword;
vSecondAddress : longword;
begin
vContent := KeepLowBits( Value, Bits );
vMask := KeepLowBits( 4294967295, Bits );

vShift := DestBitIndex and 7;

vFirstContent := ShiftLeft( vContent, 0, vShift );
vSecondContent := ShiftLeft( 0, vContent, vShift );

vFirstMask := ShiftLeft( vMask, 0, vShift );
vSecondMask := ShiftLeft( 0, vMask, vShift );

vFirstAddress := longword(DestAddress) + (DestBitIndex shr 3); // div 32
vSecondAddress := vFirstAddress + 4;

Plongword(vFirstAddress)^ := (Plongword(vFirstAddress)^ and not vFirstMask)
or vFirstContent;
Plongword(vSecondAddress)^ := (Plongword(vSecondAddress)^ and not
vSecondMask) or vSecondContent;
end;

Bye,
Skybuck.
 
Can the lack of bit field instructions in the x86 instruction set be
Certainly not, since bit-fields are both obvious and have been implemented
in a variety of machines for the past 50 years or so.

That doesn't stop people from filing patents on bit field instructions.

Maybe intel/amd is scared of law suits ?
They aren't worth it. On the few occasions when you need the facility, a
mask and shift takes just two more instructions. (For comparisons or
arithmetic on similar bit-fields, you can even omit the shift step.)

This will work up to a certain point... mostly when it's possible to
shift-or bits into single memory cell or registers.

As soon as multiple memory cells have to be overwritten things can get quite
nasty... especially if bits need to be preserved...

So I don't agree with you.

A simple example where "extract bits" instruction could be usefull is for
huffman decompression... where huffman codes can have a number of variable
bit fields stuck next to each other.

Extracting those bit fields (huffman codes) requires multiple x86
instructions, which slows down the huffman decoder.

A single instruction to do that would be preferred and would
probably/possibly give higher decoding speed and this is just one but an
important example ! ;)

Bye,
Skybuck =D
 
Barcelona (AMD) introduced 5 (or was it 7) bit manipulation
instructions.


And the original (A stepping) '386 had Insert Bits and Extract Bits
instructions. Apparently Intel needed the microcode space, and pulled
them in the B steppings.
 
So that means that BT, BTC, BTR and BTS were not sufficient? Your bitfields
must be larger?

Single bit "fields" are totally inadequate, and the x86 instructions
rather more so.

Mitch
 
MitchAlsup said:
Single bit "fields" are totally inadequate, and the x86 instructions
rather more so.

Totally inadequate *FOR WHAT*? Why are the instructions you propose
better than shift and mask?

-hpa
 
Single bit "fields" are totally inadequate, and the x86 instructions
rather more so.

Mitch


Simple answer:

One is CISC, and the other is RISC.
 
Can the lack of bit field instructions in the x86 instruction set be
explained by patents held by other cpu designers like motorola ?

The IBM 7030 computer, STRETCH, made out of discrete transistors, had
bit field instructions.

But most computers don't. The IBM 360 didn't. The x86 architecture
started out from the 8086, a 16-bit architecture built to look as much
like an 8-bit 8080 as possible... and so when it grew, it added the
most important and popular operations, like floating-point arithmetic.
Bit-field operations are regarded as very special-purpose.

John Savard
 
A simple example where "extract bits" instruction could be usefull is for
huffman decompression... where huffman codes can have a number of
variable bit fields stuck next to each other.

Extracting those bit fields (huffman codes) requires multiple x86
instructions, which slows down the huffman decoder.

A single instruction to do that would be preferred and would
probably/possibly give higher decoding speed and this is just one but an
important example ! ;)

It's not an important example and almost certainly doesn't support your
case anyway. For one thing, Huffman decoding is probably limited by memory
bandwidth and not CPU speed. More importantly, though, any really complex
instruction would either be implemented in microcode or would do something
really awful to the pipeline, resulting in a huge performance hit for
every other workload.
 
You mention bandwidth.

You mention the program being limited by bandwidth.

That more or less proves my point.

Many computers programs nowadays use 8 bits, 16 bits, 32 bits where maybe
only 24 bits where needed or 23 bits, or 22 bits or whatever.

Nowadays these programs might be wasting bandwidth by using too much space
for the storage:

Examples:

var
DataArray : array[0..100000000000000000000000] of integer;

versus:

var
DataArray : array[0..100000000000000000000000] of 22 bits;

The ammount of bandwidth savings and therefore speed gains is left as an
exercise for the reader ! ;)

Bye,
Skybuck.
 
Skybuck said:
Hello,

I have a question for you:

Can the lack of bit field instructions in the x86 instruction set be
explained by patents held by other cpu designers like motorola ?

Or is there another reason why x86 instruction set is missing bit field
instructions ?

I doubt it is for patent reasons. The DEC VAX had bit field instructions also.
 
Skybuck,



Yeah, and they might not be. Go look up some classic CISC vs. RISC history --
adding more instructions pretty much always makes you give up something else,
and while just adding a few bit-oriented instructions is not going to be that
significant, you can really get carried away to the point where your assembly
language is almost as fancy as something like C, at which point performance
almost always suffers.

Also keep in mind that when the 8086 was designed, memory was pretty much as
fast as the CPU itself... although it cost of a lot of money. These days,
memory is dirt cheap... but it's hundreds of times slower than the CPU core.

---Joel

Even without cache, DDR2 peak memory bandwidths of 6400 MB/s are
readily acheivable for sequential reads. Assuming a 3 GHz single core
might eat 6000 MB/s in instructions and 6000 MB/s in data, the speed
ratio is hardly in the hundreds. With typical locality largly
absorbed (maybe 75%) in cache, the required memory bandwith is not
more than 6000 MB/s peak and 3000 MB/s sustained. Nicely within the
available speed of current memory.
 
Back
Top