Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!amdahl!nsc!roger
From: roger@nsc.nsc.com (Roger Thompson)
Newsgroups: comp.arch,comp.sys.nsc.32k
Subject: Re: NS32532 Patents
Message-ID: <4219@nsc.nsc.com>
Date: Sun, 19-Apr-87 01:20:44 EST
Article-I.D.: nsc.4219
Posted: Sun Apr 19 01:20:44 1987
Date-Received: Sun, 19-Apr-87 17:47:44 EST
References: <4206@nsc.nsc.com> <863@oakhill.UUCP>
Organization: National Semiconductor, Sunnyvale
Lines: 71
Xref: mnetor comp.arch:1000 comp.sys.nsc.32k:89

In article <863@oakhill.UUCP>, davet@oakhill.UUCP (Dave Trissel) writes:
> some of the other things in your list I don't address.  But if you take into
> consideration all of the other microprocessor firms representing themselves
> in this newsgroup, I would be rather suprized if your list doesn't turn to
> zip.

We'll see what transpires ---- the list could even get longer, but
the length of the list won't change how the features of the 32532
operate togehter.

> Motorola offers this via several means.  First, a non-cachable bit in our
> MMU descriptor can be used to indicate I/O space.  Second, a class of
> instructions which lock the bus automatically avoid using on-chip cache.
> Third, external hardware can signal any bus cycle to be non-cached thus
> forcing the next reference to again come out onto the external bus.

I presume your references here are to the 68030 since the 020 doesn't
support a data cache.  The non-cachable bit is the classic solution,
special classes of instructions which lock the bus??? I understand
the need for bus interlocks and yes in this case you wish to avoid
the cache ----- but how does this relate to Memory mapped I/O.

My comment relates to physical I/O devices and the mechanism we
have designed into the 532 to both force an external cycle (via 
hardware) as well as to serialize read and writes.  This is required
since the internal pipeline normally prioritzes reads over writes.

> The MC68010 (out about 5 years now?) supported this for it's DBcc set of
> branch instructions (loop mode.)  Yes it was more primitive, but the idea
> is the same.

Computer architecture continues to evolve -- I agree and the designers
of tomorrows micros will borrow from the past BUT in the process
they will add new wrinkles.  What is the effectiveness of the 010s
prediction, what overall performance gain/loss does it provide since
it is only supported in one class of branch instructions.

> The MC68020 does this.  Instruction references go to both the on chip cache
> and to the bus controller.  The bus controller aborts it's cycle if the cache
> comes up with the data.
> 
The concept is quite similar, BUT far more complicated in the case
of the 532 since it also has an internal MMU.  Yes you say the
030 will support that.  Yes --- but the 030 really only supports the
TLB and even then the caches are virtual.  The 532 contains the
whole MMU , with a 64 entry TLB, and physical caches both quite
a bit larger than on the 030.

> The MC68020 has a one buffer write mechanism.  Intel claims that both their
> 286 and 386 chips support a one buffer write queue also.

Agreed, but the new wrinkle here relates to how it reacts to bus errors
interrupts, traps and other activities which affect the performance of
the pipeline.

> Most later day microprocessors could make this claim.  Do you have
> unique logic on the part to accomplish this?

Yes ---- the issue gets interesting since the 32532 supports dynamic
bus sizeing.  There are situations where intructions are fetched
both sequentially and non-sequentially.

> Again, unique logic on the part is necessary for a patent here.
> 
That is the requirement of the patent office.


Sorry for the delay in responding Dave --- but I think I'm caught
up now.

	     Roger