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
------------------------------------------------------------------------------