[Top] [All Lists]

Re: In r4k, where does PC point to?

To: karthikeyan natarajan <>
Subject: Re: In r4k, where does PC point to?
From: Dominic Sweetman <>
Date: Mon, 19 Jan 2004 17:08:20 +0000
Cc: Ralf Baechle <>, Dominic Sweetman <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
> Am curious to know, how the PC register can be used to
> locate the instruction which caused the exception as 
> the exception can happen at any one of the eight 
> pipeline stages..

You can't, of course, because there isn't a "PC register".  But now I
understand your question...

Most MIPS implementations actually respond to all exceptions at the
same pipe-stage.  (If you took exceptions when you first noticed them,
an early-stage event like a I-side TLBmiss might happen before a
D-side TLBmiss for an instruction which is earlier in the instruction
stream... and that would be bad.  We're pretending this is a
sequential processor).

So exception conditions detected early in the pipe set a flag which is
then carried down the pipeline and always looked at in the same stage.

The choice of which stage to do this is somewhat implementation
dependent; it wants to be the last stage where you can find out that
an exception is needed.  Generally that will be about the same time as
you'd access the D-cache (you may get exceptions when you're
translating the D-address).

So there needs to be a way to figure out the address where the
instruction currently at the "X" pipestage came from.  You need that
for exceptions; but you also need it (for example) when executing a
'jal' instruction and figuring out the return address.

A conceptually simple way to do this is to carry the instruction's
address along the pipeline with it, in case you need it.  But
sometimes CPU designers do something more complicated to save the

> Here is the link..
> The documentation about the PC is present in the chapter-1 under the
> section "CPU Register Overview".
> Please let me know whether this manual is correct.

Ah, that book.  That picture is nonsense, really.  Sorry, that

Dominic Sweetman
MIPS Technologies.

<Prev in Thread] Current Thread [Next in Thread>