nathan binkert wrote:
>> Whether there's an interrupt available is already tracked by ISA
>> dependent code by the Interrupts object which lives at commit. Why does
>> fetch need to know? Anything it fetches is just going to get blown away
>> anyway.
>>     
>
> The point is, you want to redirect fetch intelligently.  When there is
> an interrupt, you just want to insert it into the instruction stream
> (like an asynchronous branch), not treat it like an exception.  If you
> treat it like an exception, as you say, you blow a lot of useful work
> away.  There's no reason to do this with an interrupt.  Interrupts are
> already expensive operations.  It would not be good to unreasonably
> make them more expensive (especially if real machines don't).
>
>   Nate
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>   

Well, that's how it works today anyway. If you write to the TC I'm
pretty sure you flush the pipe, and you need to flush the pipe to vector
to an interrupt. As I'm sure you would imagine, checking whether
interrupts are enabled are not isn't just checking if your in a
particular mode in X86. There's an interrupt flag, possibly a second
interrupt flag if you've implemented those features, certain
instructions that can't be followed by an interrupt (called an interrupt
shadow), etc. I don't know this for a fact, but I think at least
partially for these reasons X86 machines flush the pipe on interrupts.
If I'm remembering correctly that matches with what I'm reading in this
book about the K6.

How is speculation handled? What if you speculated you were doing
something that would enable interrupts, started processing one which
clears the pending interrupt, etc., and then discovered you were wrong?
If you have to wait until you're not speculating any more, isn't that
the same as just waiting and doing things in commit?

Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to