Xref: utzoo comp.sys.ibm.pc:29821 comp.sys.intel:833
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!rit!cci632!ccicpg!conexch!rob
From: rob@conexch.UUCP (Robert Collins)
Newsgroups: comp.sys.ibm.pc,comp.sys.intel
Subject: Re: 80286, 80386 LOADALL instructions.
Keywords: LOADALL 80386
Message-ID: <30480@conexch.UUCP>
Date: 6 Jun 89 00:59:09 GMT
References: <30105@conexch.UUCP> <213@guardian.UUCP>
Reply-To: rob@conexch.UUCP (Robert Collins)
Organization: The Consultants' Exchange, Orange County, CA.  (714) 842-6348
Lines: 27

In article <213@guardian.UUCP> peter@langlab1.hf.intel.com (Peter Plamondon) writes:
>
>Although I don't speak for Intel and have no involvement with the chip
>designers, I've heard from a reliable source that future steppings of the
>Intel386(tm) will NOT recognize the LOADALL instruction.  Intel is rewriting

I too have heard from reliable sources (very high sources) that Intel is
speaking out of both sides of their mouth (so what's new about this from
Intel?).  While they are publicly saying they are going to remove the
'386 loadall (opcode 0f07) in the next stepping, they in fact have no
intension of removing it at all.  They just want people to quit calling
them asking about the instruction.  So by threatening to remove it,
people will be afraid to use it.  Another source (not inside Intel)
claims that the '386 Loadall (0f07) is also on the '486 mask.  I don't
have any '486's at work yet to verify this, so I make no claim to its
validity.

I have a written document from Intel stating their intension to remove
the '386 loadall from the next mask...but that doesn't mean I believe
it.  In fact, to the contrary, I don't believe it.  I subscribe to the
theory that Intel is just tired of the phone calls.

-- 
"Worship the Lord your God, and serve him only."  Mat. 4:10
Robert Collins                 UUCP:  ucbvax!ucivax!icnvax!conexch!rob
HOMENET:  (805) 523-3205       UUCP:  uunet!ccicpg!turnkey!conexch!rob
WORKNET:  (805) 378-7901