Xref: utzoo comp.sys.intel:1432 comp.arch:18776 Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!milton.u.washington.edu!jsp From: jsp@glia.u.washington.edu (Jeff Prothero) Newsgroups: comp.sys.intel,comp.arch Subject: Intel bugs / bugged by Intel :-( Message-ID: Date: 25 Oct 90 22:54:58 GMT Sender: news@milton.u.washington.edu Organization: Biological Structure, U of Wash, Seattle Lines: 96 I'm upset. Twice in six months I've spent a week or so tracking down a bug, only to find that it's in my '386 instead of in my code. That's not why I'm upset -- I know this is the computer industry, where defective merchandise doesn't entitle you to a repair, a replacement, or even an apology :-). I'm upset because (after a month or so of playing ring-around-the-rosie, accumulating manuals I don't need) I'm told that Intel considers known bugs in their chips to be proprietary and confidential information. This policy strikes me as reprehensible and downright stupid. There are a *lot* of '386s out there, some of them in embedded systems performing life-critical tasks. It doesn't take much imagination to construct a scenario leading from a deliberately suppressed bug report to bodybag(s) to a massive lawsuit. My questions: Does anyone want to explain why Intel adopted this policy? Does anyone want to *defend* this policy? Is this SOP in the industry? Do Motorola, AMD, NS ... follow the same policy? Can I go to Motorola for a list of known Intel bugs, and vice versa? Is there a net archive of known bugs? Any interest in forming one? Any other affordable source? Any reports to contribute? For the the record, the latest bug is that a POPAD followed by a MOV ECX, [EDX+EDI] will clobber EAX. It appears that Intel got a little too aggressive on the pipelining here, and that the final POPAD cycle (which restores EAX) is being trashed by the address unit computations for [EDX+EDI]. Here's some code to reproduce the problem, provided courtesy of John Lauro (jal@acc.flint.umich.edu). The bug has been detected on an old 16MHz '386 and a new 25MHz DX, and not on an SX. We haven't checked any other machines. jsp@milton.u.washington.edu ---- Cut here ---- .386 DATA SEGMENT USE16 PUBLIC MOK DB 'POPAD ok',13,10,'$' MNOTOK DB '*** POPAD fails test ***',13,10,'$' DATA ENDS ; ; STKSEG SEGMENT USE16 STACK DW 100 DUP(?) STKSEG ENDS ; ; CODE SEGMENT USE16 PUBLIC ASSUME CS:CODE,SS:STKSEG,DS:DATA CODES PROC FAR START: MOV AX,DATA MOV DS,AX mov eax,12345678 mov edx, 0 mov edi, 0 pushad popad ; The instruction immediately following popad is the critical ; instruction. Simple fix, insert a NOP after popad. mov ecx, [edx+edi] cmp eax, 12345678 je ok mov dx, offset mnotok outmsg: mov ah, 09h ; ConStringOutput int 21h mov ah, 4ch ; Exit mov al, 0 int 21h ok: mov dx, offset mok jmp outmsg CODES ENDP CODE ENDS END START ---------------------------------- -- - Jeff (S)