Double-Sigma or not

[H3nrik V!]

So, I need to be enlightened, as I can't seem to find any information of the subject.

What was actually the "32-bit multiply bug" on the first Intel 386's? And would there actually exist processors with the same sspec, but one having the bug and another don't?

AFAIK it doesn't relate to any specific production lots or similar? But please, enlighten me

[ph4nt0m]

This 32-bit multiply bug could hang up the entire machine. It's far more serious than just an incorrect result. Intel has never bothered to explain the reasons behind the bug, but it seems power consumption related because multiplication is one of the most expensive ALU opcodes and running the CPU at a lower clock speed could help with the issue.

BTW these early steppings (A0, A1, A2, B0) can be detected in software. They can execute XBTS (0x0F 0xA6) and IBTS (0x0F 0xA7) opcodes which have been dropped from B1 and later steppings. There are still way too many bugs (errata) in B1. It was C0 when Intel did their work right finally.

[rjluna2]

I may have pre-B stepping on 80386 CPU. I need to find one somewhere in my collection.

To make my story short, I attempted to installed Windows 95 on my IBM PS/2 Model 80 many moons ago and reported that the machine did not have the B-stepping CPU. I attempted to buy another 80386 at one computer dealer store, they laughed at me. So, I went to another store and a person was happy to sell me for US$ 25 for a 80386 CPU. I replaced the CPU and the Windows 95 was able to install to the machine

[H3nrik V!]

But still again .. A CPU with a given s-spec could or could not have the bug?

[frag_]

It can be both.
Look e.g. at stepping S40344 here:
http://chipdb.org/cat-16-289.htm
There are three distinct species:
- no marks
- "16 bit s/w only"
- double sigma

First one is from 1986 when they did not test it for this bug.
Then in early 1987 they started to test and mark it accordingly.
Why this bug can be both present and not present on the same s-spec?
Because it is analog one, not digital (like FDIV).
It must be tested to determine it.
It's frequency, voltage, temperature dependent thing.

As I understand it was caused by non-optimal layout of the chip.
Some combinations of arguments lead to the situation when long chain of logical elenets does not able to produce right state on the end within the given time limit.
In this sense mul32 was the "longest" operation, mul16 was much shorter and not affected.
Muls were in fact a series of adds but it was slightly more complex than simple add which was not affected.
Not sure if it can crash system beyond producint incorrect result.
Afaik windows installers tested it by 0x81 x 0x0417A000 multiplication.
Intel fixed layout of the next steppings, but still marked it with double sigma.

[H3nrik V!]

So being an analog problem, it might be that the physical placement of the actual chip in the wafer may have affected whether or not a unit had the bug or not?

[ph4nt0m]

It is also related to power supply and mainboard quality. We don't know what exactly Intel has done in order to re-evaluate these CPUs.

[CHips]

Interesting... In this case I wonder if A80386-12s are actually bugged -16s that work fine at 12 MHz...
Or whether the 16 bits S/w Only would work fine at 12 MHz...

[frag_]

Yes, any thing that affects silicon quality automatically has effect here.

Yes, very likely bugged 16 parts are works perfectly at 12.
But known 12 parts were made before this bug was discovered.

I have one "16 bit s/w only", but it passes the test at 16 MHz
Probably was tested in different conditions.

[xsecret]

I hope to be able to investigate that bug in a very deep level with the UCA one day Very interesting.