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

[Quadibloc]

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

 

[Quadibloc]

Yeah, tragic mistakes, selecting Intel and Microsoft. It could have
been Motorola and DR.

It could have been Motorola. Or it could have been Intel and Digital
Research. Oh, there _was_ a CP/M 68K, but that would have been very
unlikely...

Anyways, there *was* the Macintosh. Apple, not IBM, is at fault for
playing its cards so badly as to hand Microsoft the Windows monopoly.

John Savard

 

[FunkyPunk FieldEffectTrollsistor]

It could have been Motorola. Or it could have been Intel and Digital
Research. Oh, there _was_ a CP/M 68K, but that would have been very
unlikely...

Anyways, there *was* the Macintosh. Apple, not IBM, is at fault for
playing its cards so badly as to hand Microsoft the Windows monopoly.

John Savard

Yes, they did, and it was not necessarily a big mistake.

Apple DID make a HUGE mistake, however, by price point alone.

That mistake will be their curtain call in this economy. I would not
be buying Apple stock any time soon.

 

[MooseFET]

It could have been Motorola. Or it could have been Intel and Digital
Research. Oh, there _was_ a CP/M 68K, but that would have been very
unlikely...

Intel had their own OS called ISIS back then. It was used on there
8080 based development systems. In some ways it was more advanced
than DOS or CP/M of the same era. It had device independent I/O so
that the printer etc was handled just like a file. There was no need
for special entry points for printing.

ISIS also did a fairly cute thing on its command line parsing. It
only parsed the name of the program to be run and ran it. It left
the :CI: (stdin) pointing on the line just after the name. The meant
that if you redirected the input to a file, it was easy to implement
IF functions etc for script files.

The passing of parameters to script files was a little clunky but it
worked. The whole file was processed and the parameters were inserted
making a new file that was then used as the input to the command line
code.

 

[MooseFET]

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/

 

[Ken Hagan]

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.

 

[Skybuck Flying]

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.

 

[richard]

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.

 

[Terence]

When I began to program in ASM on Z80 (enhanced i8080) I didn't have this luxury.

(of MUL and DIV)

Hm! And when I started (pre Z80, and Bill and the Steves were were
playing with trains) there wasn't ADD or SUBTRACT either; arithmetic
was in BCD and all math was by table look-up for ADD and SUBTRACT and
subroutines using these for MUL and DIV; the screen was an
oscilloscope and the keyboard a teletype.

 

[Steve]

(Dave Platt) writes:

- Intel has always favored backwards-compatibility in their
instruction set. They don't like making incompatible changes, and
haven't had terribly good luck in the market when they did try
(read up on the IA-84/Itanium architecture and its instruction set,
which did *not* achieve great market success).

I was reading along expecting the Intel 432 to be mentioned... and
you came up with the Itanium. Oh well, possible better known.

Cheers,

Steve N.

 

[MooseFET]

(Dave Platt) writes:



   I was reading along expecting the Intel 432 to be mentioned..

Intel has tried to burn all records that there ever was a 432. It was
proposed just at the same time as the 286 came out. Its performance
sucked. N 286s would always outperform N 432s and do so on far less
power.

It is unfortunate that we are stuck going down the x86 path but that
is the one where everything seems to have gone.

 

[Vladimir Vassilevsky]

MooseFET wrote:

Intel has tried to burn all records that there ever was a 432. It was
proposed just at the same time as the 286 came out. Its performance
sucked. N 286s would always outperform N 432s and do so on far less
power.

IIRC the i432 was actually a chipset comprising of 3 different ICs,
whereas 286 was a single chip.

It is unfortunate that we are stuck going down the x86 path but that
is the one where everything seems to have gone.

It is weird that the virtual memory and the memory protection was
available since 286 yet neither OSes no applications use it because it
comes against the programming paradigm of the flat memory.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[Nobody]

It is weird that the virtual memory and the memory protection was
available since 286 yet neither OSes no applications use it because it
comes against the programming paradigm of the flat memory.

The segmentation was used quite extensively if you actually had a 286,
e.g. XMS (DOS) or 286-mode (Windows 3.1). But the 8086 didn't have it, and
the 386 offered a 32-bit flat address space, with memory protection
available on pages, so everything used that rather than segmentation.

But the 286 had such a short reign. Initially, most applications retained
8086 compatibility, so any use of 286-specific features tended to be
isolated. By the time that the 8086 really started dying off as a viable
platform, the 386 was out. So the 286 basically got leap-frogged.

 

[Stephen Fuld]

MooseFET wrote:

snip

It is unfortunate that we are stuck going down the x86 path but that
is the one where everything seems to have gone.

ISTM that most of the arguments against the X86 come down to
"aesthetics". While I agree that it is ugly, it has shown itself to be
capable of very high performance and extensibility (new instructions,
wider addressability, new addressing modes, etc). You can do low power,
but perhaps not as low as a different architecture 64 bit chip could be,
but I suspect the difference would be modest.

So other than aesthetics, what is wrong with X86?

 

[Stephen Fuld]

Jim Thompson wrote:

snip

Weren't there a year or two of 286-based PC's?

I don't know for how long, but there certainly were some, both BY IBM
and Compaq, and probably others.

The XT?

No, the XT was the 8088 with a hard disk. The 286 based models were the AT.

 

[Vladimir Vassilevsky]

Jim Thompson wrote:

snip




I don't know for how long, but there certainly were some, both BY IBM
and Compaq, and probably others.


No, the XT was the 8088 with a hard disk. The 286 based models were the
AT.

There used to be the XT 286 models as well. The same XT architecture yet
using the 286 CPU.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[Vladimir Vassilevsky]

ISTM that most of the arguments against the X86 come down to
"aesthetics". While I agree that it is ugly, it has shown itself to be
capable of very high performance and extensibility (new instructions,
wider addressability, new addressing modes, etc). You can do low power,
but perhaps not as low as a different architecture 64 bit chip could be,
but I suspect the difference would be modest.

The x86 is not too bad. Actually it has its roots from i8080. I can only
imagine if, say, PIC16 architecture was selected as a base for PC. How
would you like the dual core 4GHz PIC ?

So other than aesthetics, what is wrong with X86?

1. The x86 instruction set with the variable command length is very
inconvenient for pipelining and speculative execution. That results in
the overcomplication of the modern CPU hardware.

2. The non-orthogonal set of registers makes the code optimization a
non-tractable problem.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[Robert Redelmeier]

Unless you want to do excessive stuff like loops within
loops, or accessing more than one data structure at a time.

Then you just go to PUSH / POP semantics for nesting.

Some might view x86 as short on registers (I don't anymore).
It makes up for it with _blazing_ fast L1 cache and convenient
[EBP+..] addressing for parms & locals.


-- Robert

 

[krw]

Vladimir Vassilevsky wrote:
2. The non-orthogonal set of registers makes the code optimization a
non-tractable problem.

Not at all: 16-bit x86 code has so many registers statically allocated
that a compiler pretty much has all those decisions fixed up front.

I.e. with SI/DI for source/destination, CX as shift count/loop count,
DX:AX as the accumulator, BX for any needed table lookup or indexing,
and BP for stack frames, there's nothing left to do.

Unless you want to do excessive stuff like loops within
loops, or accessing more than one data structure at a time.

Then you just go to PUSH / POP semantics for nesting.

Some might view x86 as short on registers (I don't anymore).
It makes up for it with _blazing_ fast L1 cache and convenient
[EBP+..] addressing for parms & locals.

It's barbaric. Intel just applied massive amounts of cmos process
technology and illegal business tactics to a stupid architecture.

There is some pretty good microarchitecture in there too. Don't
forget, Intel isn't the only one to apply some pretty impressive
lipstick to the x86 pig. Many better than that of Intel.

Interestingly, all their attempts at better architectures have been
expensive failures. i432, i960, Itanic, ARM.

Because they can.

Itanic was part of your "illegal business tactics" (and "stupid
architecture" ;-).

 

[Nobody]

Not at all: 16-bit x86 code has so many registers statically allocated
that a compiler pretty much has all those decisions fixed up front.

I.e. with SI/DI for source/destination, CX as shift count/loop count,
DX:AX as the accumulator, BX for any needed table lookup or indexing,
and BP for stack frames, there's nothing left to do.

That's makes naive code generation easy, but it also makes optimisation
really hard. Optimisation means using all of the registers, not just the
"right" ones. Highly optimised code often uses -fomit-frame-pointer, to
allow EBP to be used as a general-purpose register. Needless to say, that
makes accessing parameters and local variables rather ugly.