Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: several concurrent memory ops
Message-ID: <444@m3.mfci.UUCP>
Date: 22 Jun 88 13:20:17 GMT
References: <2417@mipos3.intel.com> <2450@obiwan.mips.COM>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 44

In article <2450@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes:
>
>In article <2417@mipos3.intel.com>, Ken Shoemaker (kds@mipos2.intel.com) said
>	> But one very important constraint that John imposed was that
>	> the processor/data memory system allow only one external data
>	> access at a time.  This just isn't a requirement with the current
>	> level of integration possible on chips: having multiple pending
>	> external cycles is something that is certainly possible.
>
>I believe Ken's right... it seems doable even with single chip micros.
>
>But does this introduce lots of new headaches and trauma?  Specifically,
>if n>1 external data accesses are going on at the same time, would you
>allow more than one of them to be writes?  One might imagine an ugly
>situation where the "second" write (taking a sequential view of pgm
>execution) completed but the "first" write caused an exception ... bus
>error or some such.  Backing out of this to handle the exception and then
>restarting the user program could get dicey.  Does this lead to
>`imprecise interrupts'?

Sure you can let >1 be writes.  In fact, you'd better allow this, if
you're going to interleave your memory banks (and you'll want to do
*that* if your CPU is much faster than your DRAMS and you need a lot
of memory).  

What kind of "bus error" are you pondering?  If you're thinking of an
access violation, then (I think?) you can just blast the process and
dump whatever state would be helpful to the programmer on the way
out.  If you're considering a transient in the hardware, like a
parity error on the bus going to memory, again I'd say you might
either blast the process (and start up some machine-check code) or
you might try to salvage the task.  In the TRACE one can have many
memory references in flight simultaneously, and enough info to
restart each is kept in a queue on each CPU board.  If an exception
occurs (including a TLB miss) then the trap handler must sort through
these queues and get each reference completed before returning control
to where the trap occurred.  I don't think this constitutes an
imprecise interrupt, since the state of the machine can be fixed
exactly.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090