Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!joyce!sri-unix!garth!walter From: walter@garth.UUCP (Walter Bays) Newsgroups: comp.arch Subject: Re: several concurrent memory ops Message-ID: <788@garth.UUCP> Date: 24 Jun 88 08:25:08 GMT References: <2417@mipos3.intel.com> <2450@obiwan.mips.COM> <444@m3.mfci.UUCP> Reply-To: walter@garth.UUCP (Walter Bays) Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 27 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 ------------------------------------------------------------------------------