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