As I mentioned before, ARM has an IT instruction which choses a
condition to predicate up to the next 4 instructions on. The particular
condition and the number of instructions left to predicate are available
in a control register and are set/saved/loaded to save context on
interrupts and faults, I think. There are several different possible
ways to handle these.
The state bits could be encoded as part of the PC like the current
operating mode is now, aka. thumb vs. arm, etc. This would functionally
work, I think, but since the number of instructions changes every time
one executes, every instruction would be an unrealistic branch
mispredict. Something that's supposed to improve performance by avoiding
branching would actually be substantially worse than branching.
Another approach might be to put these bits in a pseudo integer
register which gets updated and passed along, instruction to
instruction. This would set up an unbroken chain of dependencies between
consecutive instructions, effectively eliminating all instruction level
parallelism.
The approach that I'd like to pursue is to keep track of the IT
related state in the predecoder, to update it speculatively when
predecoding an it instruction and subsequent instructions, and to pass
that information along in the ExtMachInst. The IT state would be
factored into the instruction behavior, and for instructions that read
the IT state they can look in the ExtMachInst. A catch in all this is
that some of the thread state is implicitly stored in the instruction
stream, and there's no convenient way I know of to get at it from, say,
a ThreadContext. The instructions avoid that problem by implicitly
having access to it, but faults, resetting state on mispeculation, etc.
wouldn't.
Does anyone have any suggestions? Since the third approach doesn't
seem to be fundamentally flawed like the other two and can stay isolated
to the ARM predecoder in the simple CPU, I'm planning to go ahead with
it soon. Please let me know if you either have an objection to things
working that way, a better plan to handle this in general, or a solution
to keeping the ThreadContex/ExtMachInst information in sync.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
