From owner-freebsd-hackers Mon Nov 10 11:56:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24048 for hackers-outgoing; Mon, 10 Nov 1997 11:56:54 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from unix.tfs.net (root@unix.tfs.net [199.79.146.60]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24043 for ; Mon, 10 Nov 1997 11:56:49 -0800 (PST) (envelope-from jbryant@argus.tfs.net) Received: from argus.tfs.net (pm3-p10.tfs.net [206.154.183.202]) by unix.tfs.net (8.8.5/8.8.5) with ESMTP id NAA24172; Mon, 10 Nov 1997 13:55:19 -0600 Received: (from jbryant@localhost) by argus.tfs.net (8.8.7/8.8.5) id NAA08623; Mon, 10 Nov 1997 13:56:37 -0600 (CST) From: Jim Bryant Message-Id: <199711101956.NAA08623@argus.tfs.net> Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711101856.LAA10693@usr05.primenet.com> from Terry Lambert at "Nov 10, 97 06:56:50 pm" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 10 Nov 1997 13:56:36 -0600 (CST) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 2.2.2-RELEASE #0: Wed Jul 9 01:01:24 CDT 1997 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > > In reply: > > > 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". [big snip] okay, i finally got some sleep, and re-read the manual... the fact that there are a limited number of r64 values and the fact that it is documented to create the exception for the register operand would indicate that it would have been tested at some point [my guess is too late to fix it]... i re-read LOCK, and found your reference, and see why i initially dismissed it... the only place you could be referring to is: "The XCHG instruction always asserts LOCK# regardless of the presence or absence of the LOCK prefix." no mention is made of CMPXCHG or CMPXCHG8B, but even running on the assumption that they share the same logic with XCHG, then the LOCK prefix is still legal, and apparently ignored. CMPXCHG and CMPXCHG8B are both explicitly documented under "notes" to be compatable with the LOCK prefix. your argument about compilers is correct. LOCK should only really be seen in OS software and device drivers. my backwards compatability argument as the reason for this only being found now still stands with or without the prefix. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+