Newsgroups: comp.arch
Path: utzoo!utgpu!watserv1!watdragon!rose!ccplumb
From: ccplumb@rose.uwaterloo.ca (Colin Plumb)
Subject: Re: Vector processors, i860
Message-ID: <1991Feb3.223732.3581@watdragon.waterloo.edu>
Keywords: Vector, array processors, i860.
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
References: <798@nvuxl.UUCP> <1991Feb3.061217.21988@watdragon.waterloo.edu> <1991Feb03.082253.12458@kithrup.COM>
Date: Sun, 3 Feb 91 22:37:32 GMT
Lines: 55

sef@kithrup.COM (Sean Eric Fagan) wrote:
> In article <1991Feb3.061217.21988@watdragon.waterloo.edu> ccplumb@rose.uwaterloo.ca (Colin Plumb) writes:
> > Return from interrupt.  [Is a bitch]
>
> You're told wrong, or I am.
>
> To do a context switch, you ned to do something like this:
>
>  [Example of reloading add pipeline]
>
> Etc.  Note that  a) you need to do that for every pipelined unit on the
> chip, and b) you need to know how many steps the pipeline has.  While it is
> not trivial, it won't take 10,000 lines of assembly code.
>
> Interrupt code should not have to do floating point code, so none of the
> pipelines should need to be saved/restored; that arduous task is saved for
> context switches alone.

By the way, you have to put exceptions back in the pipeline as well.
For the multiply pipeline at least, which is variable-length, there
is a special "reload pipe" instruction.

Howver, when I said it drops the pipeline on the floor, I meant the
instruction pipeline, where you are, in fact, provided with enough
information to reconstruct it's state, but it's not just a PC.

The worst case, as is usual with chips, is taking a page fault, since
it can occur mid-instruction and you usually want to do a context
switch while the page is loaded.

And flushing the cache requires a software loop to map each entry to
an inaccessible region of memory (no valid bits, it seems).

But the nastiest cases arise because certain instructions can't be
re-executed.  You have to emulate them in software.  Being in the
delay slot of a branch is marked with a status register flag, and if
it's set you have to go back and emulate the branch as well.  I haven't
got a manual handy, but I seem to recall there are some restrictions
on clobbering the branch decision register in the delay slot to allow
this to happen.

BTW, I've always wondered why MIPS backs up the PC to untaken branch
instructions.  At least, the reference to "determining if the
conditions of the branch were met" in the reserved instruction
exception description of Kane's book suggests it does.  It would be
fully backward-compatible to only back up on taken branches, and it
would also simplify the emulation logic if you knew you had these
semantics, because you wouldn't have to test the branch condition.

Then, you could be in two-instructions-per-cycle mode when this happens,
and I think there are a few other cases to worry about.

It's really a royal flaming mess.
-- 
	-Colin
