🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #20819

Re: 486 and 68040

#20819
From: Ken Shoemaker
Date: Mon, 17 Apr 1989 18:07
73 lines
4640 bytes
In article <12435@reed.UUCP> mdr@reed.UUCP (Mike Rutenberg) writes:
>Michael Slater writes:
>>- The degree to which clocks per instruction has been reduced.  Intel's 486
>>   provides single-clock loads, stores, and moves.  Assuming a cache hit,
>>   data can be used by the instruction immediately following the load, with
>>   no stall cycle at all.  It remains to be seen if the 040 will do this.

In addition, register to register "simple" arithmetic ops (i.e., everything
except multiply and divide) take one clock.  Pushes and pops take one clock.
Branch-not-taken takes one clock (if taken it is 3 clocks).  Immediate to
register operations take one clock, even though one operand is in memory.

A memory to register operation takes two clocks, but then again, this would
require two instructions plus a load delay (i.e., 3 clocks without code
reorganization) in most RISC processors.  A register to memory operation
takes three clocks, but this would take three instructions plus a load delay
in most RISC processors.  Of course, RISC processors would try to minimize
the number of memory operations required by keeping more results in on-chip
registers.

Two advantages of complex instructions that we could take advantage of here
is in the implementation of the push and pop and immediate operands.  As
said before, push/pop take one clock, even though that operation requires a
memory operation and an increment/decrement of a register.  By knowing the
kind of operation required, we were able to dedicate special hardware to do
these things concurrently.  The same is true with immediate variables.  And
it doesn't add critical paths to the chip.  Because these are defined complex
operations, one can perform multiple operations per clock in special, but
well defined (and frequently occuring) cases.

>
>From my memory, the other things that stand out about the i486:
>	* call and return now take significantly fewer clock cycles.
>	* the on-chip fpu is much faster than the 80387.  It was unclear
>	  if this was due simply to being on-chip or whether it involved
>	  architecture changes to the fpu.
>
>I belive the bus structure for the i860 and i486 is the same.

The bus structures of the i860 and the i486 microprocessors are similar, but
differ in two significant ways.  The first is that the i860 supports a
64-bit external data bus while the i486 supports a 32-bit, 16-bit and 8-bit
external data bus.  The second is that the i860, since it was designed with
an exposed pipeline and large data sets in mind, supports two levels 
of external memory pipelining (which allows the chip to operate at high 
speeds with real memory chips in an arena with many cache misses).  The i486
microprocessor, on the other hand, was designed with the idea that cache
hits would be the norm, and thus doesn't support pipelining, but rather
supports a burst mode on the bus.

However, the types of the signals, i.e., names and functions, and the 
fundamental nature of the bus, i.e., synchronous, 1X clock, are the same.
And they both have a KEN# pin...

>
>What support chips for the i486 and mc68040 were announced?
>

The i486 was announced with an Ethernet controller chip and an external
second-level cache controller.  It shouldn't be too difficult to get it to
work with most any of the other peripheral chips out there.

And now for the legal bit, UNIX is a trademark of whoever it is these days,
and i486 microprocessor is a trademark of Intel.  And I really only speak as
myself, not as a representative of Intel.  No, really!  If you want an
official position, seek elsewhere.  Call Intel.  We're in the phone book.
And if you want the i486 data "book" (at 176 pages, its difficult to call it
a data sheet), ask for order number 240440-001 "i486TM Microprocessor."
----------
I've decided to take George Bush's advice and watch his press conferences
	with the sound turned down...			-- Ian Shoales
Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California
uucp: ...{hplabs|decwrl|pur-ee|hacgate|oliveb}!intelca!mipos3!kds
Technical Details
Message-ID: <3913@mipos3.intel.com>
Path: arc1-ca.pugleaf.net!utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!littlei!omepd!mipos3!blabla!kds
References: <17131@cup.portal.com> <12435@reed.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!littlei!omepd!mipos3!blabla!kds
From: kds@blabla.intel.com (Ken Shoemaker)
Newsgroups: comp.arch
Subject: Re: 486 and 68040
Message-ID: <3913@mipos3.intel.com>
Date: 17 Apr 89 18:07:41 GMT
References: <17131@cup.portal.com> <12435@reed.UUCP>
Sender: news@mipos3.intel.com
Reply-To: kds@blabla.UUCP (Ken Shoemaker)
Organization: Santa Clara Microprocessor Division, Intel Corp., Santa Clara, CA
Lines: 73