colwell@mfci.UUCP (Robert Colwell) (06/22/88)
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
walter@garth.UUCP (Walter Bays) (06/24/88)
In article <2450@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes: >>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... >>Does this lead to `imprecise interrupts'? In article <444@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes: >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. The programmer would appreciate knowing where the error occured. If the PC has jumped and a register window has slid by the time the error comes back, he could be in trouble, unless... >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) ... the state of the machine can be fixed >exactly. ...unless the hardware keeps enough state information. (As we keep building our machines faster and faster, let's not forget the seat belts :-) -- ------------------------------------------------------------------------------ My opinions are my own. Objects in mirror are closer than they appear. E-Mail route: ...!pyramid!garth!walter (415) 852-2384 USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303 ------------------------------------------------------------------------------