Date: Mon, 10 Nov 1997 18:56:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jbryant@tfs.net Cc: tlambert@primenet.com, freebsd-hackers@freebsd.org Subject: Re: Newest Pentium bug (fatal) Message-ID: <199711101856.LAA10693@usr05.primenet.com> In-Reply-To: <199711100911.DAA07810@argus.tfs.net> from "Jim Bryant" at Nov 10, 97 03:11:40 am
next in thread | previous in thread | raw e-mail | index | archive | help
> In reply: > > > LOCK CMPXCHG8B EDX:EAX, ECX:EBX ; crash... pp 25-72 to > > > ; 25-73 of intel's arch & prog > > > ; manual for the pentium > > > > The same manual states that the CMPXCHG8B asserts a "#LOCK" signal, as > > does the "#LOCK" command. Also some paging situations, and "XCHG". > > where do you see this? what page? defintely not in the "Instruction > Set" chapter [chapter 25]... Look up "LOCK" instead of "CMPXCHG". > > It looks to me like they took the 486 macrocell, and extended it (easiest > > way to get binary compatability), and "forgot" the new registers when > > implementing the "#LOCK" assert test. > > the 0C8h r/m byte specifies the proper extended regs... > > > I can verify that using non-extended registers doesn't crash. > > if the backwards compatable 32-bit instruction CMPXCHG was buggy we > would have found out about this a long time ago... Why? A working compiler won't emit a "LOCK" before it... as others have pointed out, the bug is not that it doesn't work, but that it doesn't correctly signal an illegal instruction. The PPro and PII signal the illegal instruction. Try using your "backward compatability instruction" with a LOCK prefix on a PPro or PII. If my posting can't convince you, and you won't read about "LOCK", then perhaps a non-crashing machine signalling an illegal instruction can convinve you... > intel was obviously betting that things would remain 486 backwards > compatable for the market lifetime of the pentium. they had to have > tested this very early in the production cycle or late in the tooling > process. if i'm right about a coverup, it must have been a good one, > so good that they put it into the MMX. This would be a good theory, except that later 486's have portions of the Pentium macrocell embedded in them. If you read "Protected Mode Software Architecture", it's obvious that they have taken at least the CR4[VM] bit and V86 components and have retrofit them into the 486. That they were able to do this in such a way that it was cost effective (the only win they get is faster V86 mode on 486's than other 486 class chips) argues heavily for a large amount of shared silicon between the chips, and argues even more strongly for the macrocell extension theory of extended registers. Remember that Intel instructions are not mask programmed (like the 6502). Undocumented instructions are supposed to signal exceptions (unless the are in Appendix H). > > As someone else noticed, ther emay also be a cache fetch interaction > > (page fault was another thing referenced by #LOCK). > > > > Clearly, it's self-deadlocking trying to assert #LOCK. > > hmmmmmm.... > > just so we are talking apples <-> apples, i am referencing intel's > "Pentium(R) Processor Family Developer's Manual, Volume 3: > Archetecture and Programming Manual", ISBN 1-55512-247-7, (c) 1995, > order number 241430-004. covering the 1110/133, 1000/120, 815/100, > 735/90, and 615/75 cpus. I'm referencing: Pentium Processor System Architecture" MindShare, Inc. (Everyone should buy the full set of books to encourage these guys!) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711101856.LAA10693>