
Early 80386 CPUs and their errata - yuhong
http://www.pcjs.org/blog/2015/02/23/
======
msisk6
I found one of these when I was Autodesk back in the early 90s.

It's been awhile, so I'm undoubtedly remembering something incorrectly.

This was in the early days of protected mode DOS software. Some customers were
reporting an lockup issue with AutoCAD in rare instances when a particular
command was used.

It took awhile, but I finally narrowed it down to running the "3-point arc"
command on a system with a math co-processor and low memory (so it's paging)
on certain 386-20 chips.

I don't recall the exact fix, but we did put some Intel-recommended code in
the app to workaround the lockup. The 386 was quickly superseded by the 486
(which had its math co-processor built in which was huge for AutoCAD users
back then) so this entire issue quickly disappeared.

Fun times.

~~~
GFK_of_xmaspast
The 486sx, at least at the start, did not have a coprocessor at all.

~~~
marssaxman
The 486DX was the original 486 and it definitely did include an FPU. The FPU-
free 486SX came along a couple of years later. My recollection is that the SX
was originally a way to make use of 486DX chips that failed manufacturing
tests on the FPU; they'd disconnect the FPU portion of the die and sell the
busted chips as "486SX". Same trick AMD pulled with the 3-core Phenom.

~~~
GFK_of_xmaspast
The 486dx did, which is why I specified 486sx.

~~~
marssaxman
My apologies; I thought you were making a comment which was intended to be
relevant to the one you were replying to, which concerned the change from the
386 to 486DX. I am not sure what relevance the configuration of the later
486SX would have to the situation msisk6 described.

------
rwmj
Related story about Windows 95 on the B1 stepping:

[http://blogs.msdn.com/b/oldnewthing/archive/2011/01/12/10114...](http://blogs.msdn.com/b/oldnewthing/archive/2011/01/12/10114521.aspx)

~~~
makomk
I particularly liked the part where they had to use a 32-bit NOP because doing
NOP on 16-bit data at that spot would've triggered the errata.

------
userbinator
_Assembling a detailed and accurate history of the 80386, including a complete
listing of all the "steppings" (revisions), when they were released, what
"errata" (problems) each stepping suffered from, and which of those problems
were fixed by a later stepping, seems virtually impossible at this late date._

I'd guess that part of this could be because a lot of interesting info used to
be on various small now-defunct or deindexed sites. Even if it's largely
historical information, it doesn't feel right to just let it disappear, as
sometimes it can be used to solve some mysteries. It's too bad the Internet
Archive doesn't have a Google-like search function.

However, as long as this list is, it seems to be missing the somewhat more
famous POPA(D) bug:

[http://computer-programming-
forum.com/46-asm/c4c6d6725060904...](http://computer-programming-
forum.com/46-asm/c4c6d67250609049.htm)

~~~
101914
Isn't this one listed in 86LIST04.LST?

That list is still easy to find via Google? I believe it is bundled with the
Ralph Brown interrupt list.

What "doesn't feel right to me" is Google's treatment of Usenet archives.

It should still be possible to download these messages in their original plain
text format, in bulk using only the internet... i.e., without using the www
and all the cruft that comes with it.

------
rasz_pl
It might look scary if you never worked with Microchip microcontroller :)

~~~
Gracana
Hah, this resonates with me. I was so excited about the PIC32MZ family (MIPS
M4K with a decent amount of RAM and some peripherals, cool!) but the errata is
just _staggering_. These chips are "in production" but the errata is long, and
it's not just bugs and functions that fail to meet datasheet specs (which is
pretty bad by itself)... a lot of functionality is simply listed as "does not
function" or "not operational."

~~~
makomk
Yeah, this tends to happen a lot on modern microcontrollers with lots of
complicated peripherals from what I've seen, especially in pre-production
steppings of the chip

------
raverbashing
Some things seem downright scary in the first erratas

> Misaligned Selectors: If a 16-bit memory operand is loaded into a segment
> register, the 80386 hangs if the selector is not word-aligned

> Incorrect Interrupt Vector: If a maskable interrupt occurs immediately after
> the 80386 has executed an instruction with an 8-bit operand, the interrupt
> is always assigned a vector number of 0.

I can understand, since they probably did a lot of it by hand. It was also
more advanced than the 80286 being 32-bit, memory protection (though I think
some of it was on the 80286), etc

~~~
rasz_pl
Actually 386 was almost 100% autogenerated. Only bits done by hand was a glue
logic between code generated blocks.

Intel embedded its engineers at Berkeley (afaik) for a full year to work with
students on the brand new VLSI software that made 386 possible.

Intel started doing formal proofing of its logic blocks after Pentium FPU
fiasco.

~~~
smalley
I'm not entirely sure if it was quite so heavily software synthesized at that
point. I think a lot of the logic and datapath was still done by hand.

The grad student I think you're talking about is (now) Dr. Carl Sechen who
developed an Auto Place and Route tool he named Timberwolf. Those tools don't
synthesize logic so much as they choose optimal locations and orientations for
the standard cells on the wafer and then attempt to route the metal
interconnects (all with respect to timing). I think it wound up being rather
buggy (to the point they had to keep calling him back from school work to
patch some things up) and a fair number of things had to be corrected by hand.

I did hear that some of the units on the 386 were written in some Stanford
devised programming language from the pre Verilog/VHDL toolstack days and that
a few engineers in design automate hacked up a tool flow to turn that
programming language into something synthesizable.

That said I wasn't there and so I can't claim to know for sure. I would wager
there are some good interviews and documents either with the Intel Museum
folks or the Computer History Museum in Mountain View (which seems to always
have both contacts from the day and documents for all the old fun computing
hardware).

~~~
rasz_pl
I read it here
[http://webee.technion.ac.il/people/kolodny/ftp/IntelCADPaper...](http://webee.technion.ac.il/people/kolodny/ftp/IntelCADPaperFinal2.pdf)
plus some stuff written by Randal Bryant (of mossim/cosmos fame)

~~~
raverbashing
That's a great article!

