Newsgroups: comp.sys.ibm.pc.hardware
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!mmshah
From: mmshah@athena.mit.edu (Milan M Shah)
Subject: Re: AMD386-DX
Message-ID: <1991Apr11.203242.23931@athena.mit.edu>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
References: <69454@eerie.acsu.Buffalo.EDU> <3672@sixhub.UUCP> <70411@eerie.acsu.Buffalo.EDU>
Date: Thu, 11 Apr 91 20:32:42 GMT
Lines: 25

>>In article <69454@eerie.acsu.Buffalo.EDU> jones@acsu.buffalo.edu (terry a jones) writes:
>>
>>| 	I'm waiting to see if someone other than Intel offers us such a
>>| solution since it seems as though the legal precedence has been established.
>>  AMI has the right to use Intel microcode. However, there is a lot more
>>to the chip than microcode, and I don't know if the right to microcode
>>in the FPU has been established.
>>
>
>	Agreed.  But I'm not sure why they'd want to license Intel's FPU
>microcode.  I'd rather see them use Cyrix's 80387 clone on the die.  Or
>something along those lines.  I don't know how Cyrix went about producing
>their dies for the FPU, I doubt they licensed microcode to do it.
>

For most non-FPU related stuff (and I get the impression that most all
commercial software go to great pains to stick to integer math because they
must run on non-FPU equipped machines), wouldn't it be much wiser to put a
larger cache on the die itself (ie, ala 486's cache?). I would think this
would be much more beneficial for non-FPU stuff, yes?

Milan
.