HDTenEightyP/NetNews huggingface dataset:
From: philip@cs.vu.nl (Philip Homburg)
Subject: known errors/omissions in Intel 386/486 reference manuals?
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Date: Tue, 15 Dec 1992 16:57:07 GMT


Does anyone have/maintain a list of errors in the 386/486 refence manuals.
An example: Both the 386 and the 486 reference manual state that the shift
instructions set the zero flag (ZF). This is not the whole truth since
on both a 386 and a 486sx (and probably on others too) 'shr' doesn't set ZF 
if the shift count is 0. Gcc seems to know this since it generated an extra 
'test' after a 'shr' for 'if (a>>b) ...'.

Other examples include a number of bugs in tables.




						Philip Homburg



Philip Homburg 			   			<philip@cs.vu.nl>
Vrije Universiteit / Dept. of Math. & Comp. Sci.	+31 20 5483546
Amoeba project / De Boelelaan 1081A
1081 HV Amsterdam / The Netherlands
From: dmccart@gomez.intel.com (D. J. McCarthy)
Newsgroups: comp.sys.intel
Subject: Re: id in parts
Date: 16 Dec 92 00:40:05 GMT
Organization: Intel ASTG, Santa Clara, CA
X-Newsreader: TIN [version 1.1 PL8]

M. Wiltink.a73A.telnr-015-138378 (wiltinkm@dutiws.twi.tudelft.nl) wrote:

> As far as I know, but I don't know and that basically means nothing, 80x86
> processors have no code anywhere except maybe on the housing that enables you
> to tell the n'th chip produced from the (n+1)'th chip, or any other chip from
> the same line.

	I've been reading this thread and have declined to comment on
it so far mainly because I don't have a clue as to whether Intel does
anything like uniquely ID'ing each chip or not.  But if you stop to
think about it, it wouldn't make much sense.  EACH chip would have to
get stamped just a *little* bit differently from each other chip,
which would make mass production almost impossible and certainly send
production costs through the roof.

	Even putting it in some sort of ROM section later (to be
burned in at encasing time or something) would seem to me to be
extremely cost-ineffective.  But like I said, I really have no idea.


--
D. J. McCarthy (dmccart@gomez.intel.com)
Newsgroups: comp.sys.intel
From: J056600@LMSC5.IS.LMSC.LOCKHEED.COM
Subject: Re: Intel's new performance test iCOMP
Organization: Lockheed Missiles & Space Company, Inc.
Date: Fri, 18 Dec 92 19:11:16 GMT

In <1992Dec18.112919.22234@fwi.uva.nl>, Stefan Sinnige writes:


>I read in our local newspaper about a new performance test, to compare
>Intel processors. The performance test is developed at Intel itself and is
>called the iCOMP (tm) Rating. The results are as follows:

>   i486 DX2 66 MHz               297
>   i486 DX  50 MHz               249
>   i486 DX2 50 MHz               231
>   i486 DX  33 MHz               166
>   i486 SX  33 MHz               136
>   i486 SX  25 MHz               100
>   i486 SX  20 MHz               78
>   i386 DX  33 MHz               68
>   i386 DX  25 MHz               49
>   i386 SL  25 MHz               41
>   i386 SX  25 MHZ               39

>The test is developed to show which processor is more powerfull. But they did
>not tell, how the test is performed, so I do not know what these numbers stand
>for.

>Can someone bring some light in the darkness .....

I can tell one thing about their benchmarks--they clearly use the co-processor.
Otherwise, the 486SX and 486DX numbers would be identical.  That's just come-
thing to keep in mid if you don't anticipate using any applications which
use the FPU.  For apps which don't use it (well over 90% don't), the SX is
every bit as fast as the DX.

Now I know where my new 486SX/33 stands.  Where is my old 386DX/20??   :-)


Tim Irvin
******************************************************************************
Microsoft Windows--from the folks who brought you EDLIN.

Newsgroups: comp.sys.intel,comp.sys.mac.hardware,comp.sys.ibm.pc.hardware
From: bbrown@infonode.ingr.com (Bailey Brown)
Subject: Re: 486 vs. Mac Benchmarks
Organization: Intergraph Corporation, Huntsville, AL.
Date: Fri, 11 Dec 1992 19:36:44 GMT

ntaib@silver.ucs.indiana.edu (Iskandar Taib) writes:

>>Hence the suprising results, such as a IIci being faster than a 486/25
>>(in real activities such as Word scrolling) are not too far from reality.

>They must've had a Trident card in the 486. 

No, it was a PS/2 M70 with IBM's 486/25 Power Platform(TM) upgrade
board and the PS/2 built-in VGA.  The Power Platform was the SLOWEST
486/25 implementation benchmarked by Byte, and the M70's built
in VGA is legendary for its slowness.

IBM has since figured out how to make PCs that run as fast as
everybody else's.  

------------
Bailey Brown                               "Above all else, confusion reigns."
Intergraph Corporation                                  
bbrown@casca.b11.ingr.com                              Procol Harum
From: casivils@lescsse.jsc.nasa.gov (craig sivils)
Newsgroups: comp.sys.intel
Subject: Re: Intel's new performance test iCOMP
Date: 20 Dec 92 23:26:21 GMT
Organization: Lockheed Engineering and Sciences

And what about a 386 40 (I know, that ain't intel)

			Craig
From: chbl@sbustd.rz.uni-sb.de (Christian Blum)
Newsgroups: comp.sys.intel
Subject: Re: Intel's new performance test iCOMP
Date: 18 Dec 1992 15:51:38 GMT
Organization: Studenten-Mail, Rechenzentrum Universitaet des Saarlandes
NNTP-Posting-Host: sbustd.stud.uni-sb.de

sinnige@fwi.uva.nl (Stefan Sinnige) writes:
> I read in our local newspaper about a new performance test, to compare
> Intel processors. The performance test is developed at Intel itself and is
> called the iCOMP (tm) Rating. The results are as follows:
[stuff deleted]

Anyone any idea where to get this test program?
--
---------------------------------------------------------------------
Christian Blum                   Universitaet des Saarlandes, Germany
Friedrich-Ebert-Str. 50          chbl@stud.uni-sb.de
W-6685 Heiligenwald              chbl@sbustd.rz.uni-sb.de
Germany                          Tel (+49) (0) 6821 67476
Newsgroups: comp.sys.intel
From: lam@mrcnext.cso.uiuc.edu (Ken Lam)
Subject: Re: Intel IC spec sheet/documentation ...
Organization: University of Illinois at Urbana
Date: Mon, 21 Dec 1992 03:35:12 GMT

x90farleigh1@gw.wmich.edu writes:

>Can someone give me the info for Intel's document distribution system...
>Do they have internet mail capability?

>I need data sheets for Intel ethernet chip set, and for various documents (like
>SMB protocol).

Yes, I'd like to see chip specs online.  Maybe a gopher server or mail server.
Someone at INTEL once told me they they don't have an anonymous ftp site, so
gopher would be great!

--
Ken Lam                                                     (803)-884-7615 (H)
System Administrator                                        (803)-792-4969 (W)
Senior Systems Consultant                                   (803)-792-5446(FAX)
Netware/UNIX System Programmer/Integrator                    lam@jove.cofc.edu
MultiMedia Works & Video Productions ======= Teaching the world in better ways

Newsgroups: comp.sys.intel
From: Bruce.Weinel@p1.f456.n632.z3.fidonet.org (Bruce Weinel)
Newsgroups: comp.sys.intel
Subject: Q: What's wrong with this?
Date: 20 Dec 92 18:05:26 GMT

kovarski@zooid.guild.org was heard in "The Pit" saying to  All

  MK> From: Mark Kovarski <kovarski@zooid.guild.org>
  MK> Organization: ZOOiD BBS
  MK> 
  MK> I have the following it of code which was given to me.
  MK> Aside from the "few" errors, the person claims that
  MK> this will cause a message:
  MK> 
  MK> ON BOARD PARITY ERROR
  MK> ADDR (HEX) = (xxxx:xxxx)
  MK> SYSTEM HALTED.
  MK> 
  MK> This apparently appears when the following is run:
  MK> 
  MK> mov al,74
  MK> out 43,al
  MK> mov al,ff
  MK> out 41,al
  MK> mov al,ff
  MK> out 41,al
  MK> ret
  MK> ----------
  MK> I can not check this since I am running OS/2 and traps
  MK> the error before it appears on the screen. The person
  MK> claims that he interfers with the DMA refresh rate and
  MK> this is the reason a parity error appears.
  MK> 
  MK> Could someone check if this is the case and if so, why
  MK> the error appears. From my understanding, a parity error
  MK> can only be caused by DRAM and I/O parity errors. Furthermore,
  MK> on the PC AT, 2BH and 29H are the post addresses for the
  MK> Interrupt controller (8259A). THe Programmer's PC Sourcebook
  MK> mentiones that ports 20 and 21 are only used. There seems to
  MK> be something very strange going on with this program. Thanks...

The values given (74, 43 and 41) are in hex; just like the 'ff'. The first two
commands select Counter 1 (which controls refressh) for a 16-bit read or write
into the rate generator. The next four output FFFFh to the rate generator.
This
effectively stops (actually slows dramatically) memory refresh. Your DRAMs
then
slowly lose their charge and eventually a parity error results.

I would suggest keeping this person away from your PC.   I-{>


 * Origin: Howls from "The Pit" BBS (03) 321-3295 (3:632/456.1@fidonet)
Newsgroups: comp.sys.intel
From: gonzaled@ucsu.Colorado.EDU (LGV/MC)
Subject: Re: Intel's new performance test iCOMP
Organization: University of Colorado, Boulder
Date: Sat, 19 Dec 1992 03:12:37 GMT

J056600@LMSC5.IS.LMSC.LOCKHEED.COM writes:

>In <1992Dec18.112919.22234@fwi.uva.nl>, Stefan Sinnige writes:


>>I read in our local newspaper about a new performance test, to compare
>>Intel processors. The performance test is developed at Intel itself and is
>>called the iCOMP (tm) Rating. The results are as follows:

>>   i486 DX2 66 MHz               297
>>   i486 DX  50 MHz               249
>>   i486 DX2 50 MHz               231
>>   i486 DX  33 MHz               166
>>   i486 SX  33 MHz               136

     i486 DX  25 MHz               122

>>   i486 SX  25 MHz               100
>>   i486 SX  20 MHz               78
>>   i386 DX  33 MHz               68
>>   i386 DX  25 MHz               49
>>   i386 SL  25 MHz               41
>>   i386 SX  25 MHZ               39

     i386 SX  20 MHz               32

>>The test is developed to show which processor is more powerfull. But they did
>>not tell, how the test is performed, so I do not know what these numbers stand
>>for.

>>Can someone bring some light in the darkness .....

>I can tell one thing about their benchmarks--they clearly use the co-processor.
>Otherwise, the 486SX and 486DX numbers would be identical.  That's just come-
>thing to keep in mid if you don't anticipate using any applications which
>use the FPU.  For apps which don't use it (well over 90% don't), the SX is
>every bit as fast as the DX.

From PC Magazine, December 8, 1992:
"The current iCOMP index is made up of four weighted components: 16-bit
integer (67 percent), 16-bit floating point (3 percent), 32-bit integer
(25 percent), and 32-bit floating point (5 percent).  Those weightings
reflect Intel's best guess about the importance of each component in
applications over the next three to five years (the average system
lifetime).  But Intel expects to update the formula as new CPU
capabilities emerge (graphics and video are two likely candidates), and
as applications change (as more of them take advantage of 32-bit
technology, for example)."

The full article appears on page 31.
From: ian@spider.co.uk (Ian Heavens)
Newsgroups: comp.sys.intel
Subject: Re: Any new instructions in a i486?
Date: 16 Dec 92 09:16:55 GMT
Organization: Spider Systems Limited, Edinburgh, UK

In article <WAYNE.92Dec11164422@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:
>
>There have been a fair amount of discussion in comp.sys.intel about
>what new instructions the i486 has (and if the Cyrix 486SLC/486DLC
>implement them.)
>
>
>
>The XADD and CMPXCHG instructions are useful for implementing
>semaphores in multi-processor systems.  Not something a normal
>application would have much use for.
>

With XADD and the bus lock prefix, you can implement an atomic
fetch-and-add on a 486.  This is much more useful than test-and-set,
the only hardware support for mutual exclusion in the 80386.  Building
SMP systems from 80386s is a real pain.


ian

---
	 Ian Heavens			ian@spider.co.uk                 
 	 Spider Software
 	 Spider Park, Stanwell Street		
	 Edinburgh, EH6 5NG, Scotland	+44 31 555 5166 (Ext 4347)
--
Newsgroups: comp.sys.intel,comp.sys.mac.hardware,comp.sys.ibm.pc.hardware
From: ma106071@cs.brown.edu (Jim Lowe)
Subject: Re: 486 vs. Mac Benchmarks
Organization: Brown Computer Science Dept.
Date: Thu, 17 Dec 1992 22:33:58 GMT

In article <BzF5MF.2Lv@usenet.ucs.indiana.edu>, ntaib@silver.ucs.indiana.edu (Iskandar Taib) writes:
|> In article <1gdipoINN749@rave.larc.nasa.gov> w.l.vaughn@LaRC.NASA.GOV (Wallace L. Vaughn) write
 
|> >Mac II, 16mHz, system 7.01+, 8bit 640 x 480 video, 8 meg ram
|> >Mac IIci, 25mHz, see above
|> >386dx, 33mhz system, windows, 3.0, 640x480 svga screen, no cache. 8meg RAM
|> >                     calc.(sec)       scroll(min:sec)
|> >Mac II                    35.3            2:16.2 
|> >Mac IIci                  15.3            1:31.2
|> >Mac IIci/cache off        19.2            1:44.7
|> >386dx                     22.5            2:25.3
|> 
|> Hmmmm.
|> 
|> Most 386 motherboards above 25 MHz have a built-in SRAM cache 
|> these days. Even the bargain basement jobs.


I'd say Motorola's 680x0 series is faster than Intel's 80x86 of the same
generation, AT THE SAME CLOCK SPEED. The reason Intel's tend to be substantially
faster in reality is that Intel always offers them at a higher clock speed than
Motorola has yet achieved. e.g., the 33MHz 486 has been on the market for 2 years
or so, while the 33MHz 68040, I believe, just came out within the last two
months. (at least, the first Quadra based on it was released then).

Running a fast chip without a cache cripples it with so many wait states that it
loses its clock speed advantage entirely. The original XT didn't need a cache
because it ran at 4.77 MHz and used 210 ns DRAMs. (at 4.77 million clocks/sec.,
each clock lasts exactly 210 ns).  Think about it; clock speeds have gone up 10
times, while memory speeds have barely gone up 3 times. Trying to compare two
fast chips, one of which has a cache, and one of which doesn't, is completely
meaningless. Of COURSE the one with the cache will win by an enormous margin. As
is pointed out above, for months or years now, virtually all 386 systems have
been offered with cache.


-- 
*********************************************************************
   ----- ----- --    --  |  -----
     |     |   | \  / |  |  |
     |     |   |  -   |     -----
     |     |   |      |         |
   --     ---  -      -     ----- 
     GRANDIOSE
		and
			ANNOYING
	.signature file.
	jim lowe, cs141046@cs.brown.edu
	          ma106071@cs.brown.edu
**********************************************************************
From: x90farleigh1@gw.wmich.edu
Newsgroups: comp.sys.intel
Subject: Intel IC spec sheet/documentation ...
Date: 20 Dec 92 20:21:26 EST
Organization: Western Michigan University

Can someone give me the info for Intel's document distribution system...
Do they have internet mail capability?

I need data sheets for Intel ethernet chip set, and for various documents (like
SMB protocol).

Thank You,
 Fred Farleigh

Newsgroups: comp.sys.intel
From: cosc184z@menudo.uh.edu (David Alten)
Newsgroups: comp.sys.intel,comp.sys.mac.hardware,comp.sys.ibm.pc.hardware
Subject: Re: 486 vs. Mac Benchmarks
Date: 15 Dec 1992 11:24:03 -0600
Organization: University of Houston
NNTP-Posting-Host: menudo.uh.edu

Did the ci and/or PC have an FPU??  If I remember correctly, Excel checks to
see if you have an FPU, and uses FPU math instead of integer math if you have
an FPU installed.

I'm not too familiar with PC's, so if I missed something, please correct me.

-- 
"Listen to me, 'cause I've got something to say.  |  David Alten
 It's better to burn out, than to fade away!!!"   |  cosc184z@menudo.uh.edu
   -- Highlander                                  |  HE KUER!!
       ** T h e r e    c a n    b e    o n l y    o n e ! ! **
Newsgroups: comp.sys.intel
From: wiltinkm@dutiws.twi.tudelft.nl (M. Wiltink.a73A.telnr-015-138378)
Subject: Re: id in parts
Organization: Delft University of Technology
Date: Tue, 15 Dec 1992 12:48:05 GMT

In article <1992Dec11.155227.28583@ichips.intel.com> rminemie@sedona.intel.com (Ronald Minemier) writes:
>
>i dont know if this is what you are asking about but there is a
>JEDEC standard for internal part identification that has been in
>use for years. There is usually a manufacture's ID, Device ID,
>and stepping field used. All intel micr0-controllers have used this
>and i believe most other Intel parts.
>
>i'm not a processor guy, but clearly the data book shows for 386
>devices that the EAX register holds the part ID just after self-test
>is complete...
>-- 
> Intel, Corp.
> 5000 W. Chandler Blvd.
> Chandler, AZ  85226

That's different. This is a component TYPE identification. A 386 has a 3 in
some register while a 486 has 4. Also, different updates of the 386 (I'm
mostly familiar with the 386) have different stepping numbers in some register.

As far as I know, but I don't know and that basically means nothing, 80x86
processors have no code anywhere except maybe on the housing that enables you
to tell the n'th chip produced from the (n+1)'th chip, or any other chip from
the same line.

---------------------------------------------------------------------------
wiltinkm@dutiws.twi.tudelft.nl
Maarten Wiltink

Department of Applied Mathematics and Computer Science
Delft University of Technology
The Netherlands
From: kevinb@unssun.nevada.edu (Kevin Brewer)
Newsgroups: comp.sys.intel
Subject: Simple CPU Questions
Keywords: 486SX, x86
Date: 16 Dec 92 21:10:38 GMT
Reply-To: kevinb@unssun.nevada.edu (Kevin Brewer)
Distribution: usa
Organization: University of Nevada, Reno

I'll admit it. I use a Mac. But I have a simple(?) question about the
intel x86 CPU's. (If this is a FAQ, please direct me to the proper
place as I don't read this news group.) So here goes...

My brother-in-law just bought a 486SX machine. What is the difference
between the 486SX and the _normal_ 486 chip? FPU? 16 v. 32 bits? ???
Is there a _normal_ (full powered?) 486 chip? The 486DX?

Thanks - Kevin


 


Xref: sparky comp.sys.intel:2694 comp.sys.mac.hardware:24130 comp.sys.ibm.pc.hardware:33189
From: ntaib@silver.ucs.indiana.edu (Iskandar Taib)
Newsgroups: comp.sys.intel,comp.sys.mac.hardware,comp.sys.ibm.pc.hardware
Subject: Re: 486 vs. Mac Benchmarks
Date: 15 Dec 92 05:42:41 GMT
Organization: Indiana University

In article <Bz2C4s.FqE@usenet.ucs.indiana.edu> ntaib@silver.ucs.indiana.edu (Iskandar Taib) writes:
>In article <1992Nov26.000926.9507@doug.cae.wisc.edu> jimy@cae.wisc.edu (Jim Yu) writes:
>Hardware: IBM PS/2 Model 56Slc (386SLC, not sure about MHz)., ATI 8514/
>          Ultra video, 1024x768x 256 colors (running 8514 driver). 12 
>          Meg. RAM. 
>
>          Macintosh IICi, built-in Apple video, 680x480(yuck)x256 colors.
>          32 bit addressing turned on, VRAM on, 16 Meg available, disk 
>          cache 384K.      
>
>          In the wings (have to try this later): Clone 386-40, 4 Meg RAM,
>          Diamond Speedstar 800x600x256 color video.
>
>Software: Excel 3 (I will try it with Excel 4 in the next couple days).
>
>The test: Put an integer into cell A1. Cells B1 -> Z1 are cell to the left
>          + 1. Cells A2 -> Z1000 are cell above +1. See how long it takes 
>          to recalc the sheet after changing value of A1.
>
>Results:  Under Windows recalc took 3.3 seconds. On the Mac, 7.5 seconds.

Another data point:

AMD 386-40, 4 Meg RAM. Excel 4. 2.2 - 2.3 seconds. 

(On an Amiga 2000 - machine locked up copying 100 cells 9-) )

Next thing to try: 

Excel 4 on Si. 
Excel 4 on Ci.
Excel 4 on PS/2 Model 70 (20 MHz 386)
1234W on PS/2 Model 70.
Excel 4 on Gateway 486/33
1234W on Gateway 486/33

What I'd like others to try (I don't have the hardware/software):

Quadra 700/900 
WingZ for Windows and Mac
123 4 Mac on various Macs.

Haven't devised it yet but some silly trig-based floating point 
spreadsheet. This should show a big 486 vs. 386 (no 387) speedup.

Some kind of equally silly wordprocessing task on all the platforms.


By the way the scrolling in Excel while I was doing this was pretty
fast (Diamond Speedstar card). Not as fast as Lotus 2.0 under DOS 
on the same machine but who cares?





-- 
-------------------------------------------------------------------------------
Iskandar Taib                          | The only thing worse than Peach ala
Internet: NTAIB@SILVER.UCS.INDIANA.EDU |    Frog is Frog ala Peach
Bitnet:   NTAIB@IUBACS                 !
Newsgroups: comp.sys.intel
From: peter@ferranti.com (peter da silva)
Subject: Re: Where do you go from 486? (more opinions)
Organization: Xenix Support, FICC
Date: Thu, 17 Dec 1992 23:24:45 GMT

In article <1992Dec13.182218.22064@nmt.edu> stimpy@nmt.edu (John Reynolds) writes:
> for OS/2 2.0, I just wish more of corporate america would seriously look at
> OS/2 2.0 before investing in more wasted time with DOS or windows. Why wait
> for file transfers, disks to format, or jobs to print, when you can do 
> all of that and continue to be productive???

Just ask any Amiga user how much technical competance is worth to
corporate America...
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.sys.intel
From: J056600@LMSC5.IS.LMSC.LOCKHEED.COM
Subject: Re: 486/66 .. Into a 486/50 motherboard?
Organization: Lockheed Missiles & Space Company, Inc.
Date: Wed, 16 Dec 92 20:54:17 GMT

In <1992Dec16.155510.11854@cs.odu.edu>:


>Is it possible to replace the 50MHz 486DX chip on a 486/50 mommyboard with a
>66 MHz DX/2??  I am thinking of replacing my CPU, but I don't want to replace
>my entire motherboard if I don't have to.  Thanks.

Sure, you probably could, but would it be worthwhile?  You'd have to change
the clock crystal and the CPU.  In fact, the clock crystal would have to be
*slowed down* from 50 MHz to 33 MHz.  The addition of the DX2 would make the
CPU behave like a 66 MHz machine (instead of 50), but the rest of the machine
would act like a 33 MHz machine (again instead of 50).  If you are using
*very* CPU-intensive applications, this might help.  If you're doing things
which requires mostly disk, video or memory, a DX2/66 might be almost a
downgrade from a DX/50.  Most people I know who have seen both (I've never
seen a DX2/66) say there's virtually no difference in performance.

Another requirement for a DX2/66 is *lots* of external cache--without at
least 256K, the DX/50 would probably be faster because the DX2/66 would
encounter a lot of wait states without it.  Many people even advocate a 512K
cache.  Again, I haven't seen it, so I'm relying on opinions of people who
know more about the DX2/66 than I do.


Tim Irvin
*****************************************************************************
Microsoft Windows--from the folks who brought you EDLIN.

Newsgroups: comp.sys.intel