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

On Mar 6, 11:37*am, MitchAlsup wrote:
On Mar 5, 10:57*pm, "Skybuck Flying" wrote:

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.


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.

Harold Aptroot wrote:
"Skybuck Flying" wrote in message
b.home.nl...

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?
Well, his imagination is a BIT larger than others...

On Mar 6, 4:53*am, "Harold Aptroot" wrote:
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 wrote:
On Mar 6, 4:53 am, "Harold Aptroot" wrote:
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.

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

-hpa

On Sun, 8 Mar 2009 20:29:11 -0700 (PDT), MitchAlsup
wrote:

On Mar 6, 4:53*am, "Harold Aptroot" wrote:
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


Simple answer:

One is CISC, and the other is RISC.

On Mar 5, 10:57*pm, "Skybuck Flying" wrote:

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

On Mar 8, 8:29*pm, MitchAlsup wrote:
On Mar 6, 4:53*am, "Harold Aptroot" wrote:

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.

Obviously to make an efficient Intercal compiler, the machine should
have a native Interleave instruction.

http://www.muppetlabs.com/~breadbox/intercal-man/


Mitch

On Fri, 06 Mar 2009 21:39:32 -0000, Skybuck Flying
wrote:

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,

"Skybuck Flying" wrote in message
.home.nl...
Nowadays these programs might be wasting bandwidth by using too much space
for the storage:

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