Re: Interrupts in OoO (was: Microarchitectural support for counting)

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

EricP <ThatWouldBeTelling@thevillage.com> writes:

That's difficult with a circular buffer for the instruction queue/rob
as you can't edit the order.

 
What's wrong with performing an asynchronous interrupt at the ROB
level rather than inserting it at the decoder?  Just stop commiting at
some point, record this at the interrupt return address and start
decoding the interrupt code.
 
Ok, it's more efficient to insert an interrupt call into the
instruction stream in the decoder: all the in-flight instructions will
be completed instead of going to waste.  However, the interrupt will
usually be serviced later, and, as you point out, if the instruction
stream is redirected for some other reason, you may have to replay the
interrupt.

The CPU can give ring 0 priority, it is OoOe after all.

The interrupt likely has to touch ram, ram that is 150 cycles away. With an
8 wide cpu that is 1200 instructions drained out of your huge 800 slot OoOe
buffer.

Yet another reason the instruction counters look like garbage when you try
and use them like a microscope.

I had a $20,000 ICE (in circuit emulator) for the PlayStation 2 as my job
was optimizing game code. I got to look at individual reads and writes and
ALU state changes of instruction completion. (The ALU state is available on
undocumented pins so the hardware guys can debug, all this is dumped to a
special memory.)

As for counting, it seems to me that Brett has understood nothing of
what he cited from my posting.

My thread is more interesting and useful to readers, whereas you are lost
in the woods. ;)

Your hardware guys are not interested because they know what you want is
not useful. ICE probes could give you more info, but that tech is highly
secret and dangerous for users to get, and is fused off for your
protection. You don’t need such data, and would not understand such info if
you had it.

You are being humored just in case what you want is not too much trouble
and could be added, so continue telling us what you really want. And what
you think is broken and why, and people will tell you why you think it’s
broken is wrong.

Is there a link to a paper covering your concerns?

- anton

To really profile something accurately you need to batch your loops, so
your counters are not corrupted by code before and after the loop. Just
ignore the first few and last batches, which will give time for the
prefetch to warm up. There will be interrupt spikes, ignore those also.