Early 80386 CPUs and their errata
pcjs.org
pcjs.org
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.
http://blogs.msdn.com/b/oldnewthing/archive/2011/01/12/10114...
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...
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.
> 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
If it's a new design, with no backwards compatibility issues I guess lots of "bugs" became documentation items or "features"
I worked at Intel at the time and this "hack" really bothered me as a young engineer.
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.
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).