To differentiate between branch/no branch that's actually along the
lines of what I want to do, which in retrospect doesn't really have
anything to do with what I was talking about here. A better reason is
that there is no register file object in anything but the simple CPUs.
My working solution so far is to annotate each instruction definition
with a list of sources that might be the PC in disguise. Then in the
execute template I add a little blob of code that checks if one actually
is the PC, and if so overwrites its value with xc->readPC() + 8. I have
to make sure I write to that variable in a way that the ISA parser can't
figure out so it doesn't make it a dest too, so I wrote a little
function that takes a reference to it and it's new value and does the
assignment outside of the parsers view.
I don't have a solution for the dest end, though. I could do something
similar, but if I were to read from the variable to pass to
xc->setNextPC(), the parser would think it was a source. I haven't
thought of a good way to hide that assignment.
In both of these cases, I'm building up a non-trivial blob of stuff
trying to get operand reading and writing to do what I want them to do.
If I could get that effect directly I could just leave the instruction
definitions/formats the same.
Example reading code:
Rn = (RN == PCReg) ? xc->readPC() : xc->readIntRegOperand(this, 0);
Example writing code:
if (RD == PCReg)
xc->setNextPC(Rd);
else
xc->setIntRegOperand(this, 0);
Steve Reinhardt wrote:
> Have you looked at how the Alpha ISA detects writes to R31 to generate
> no-ops instead of regular instructions? Is there any reason that
> approach (or a similar one) wouldn't work? You may not want two
> completely different instructions like Alpha, but you could do the
> comparison with R15 in the same spot and then pass a bool into the
> constructor; that seems cleaner to me than burying the functionality
> inside op_rd/op_wb.
>
> Steve
>
> On Sun, Jun 21, 2009 at 12:41 AM, Gabe Black <[email protected]
> <mailto:[email protected]>> wrote:
>
> I'm moving ARM's R15/PC handling into the instructions themselves
> instead of the register file for a number of reasons. There are a
> number
> of difficulties associated with that, some of which I've dealt
> with and
> some I haven't. In both cases, life would be a lot easier if I had
> more
> explicit control over over the code that reads from and writes to the
> operands. I'd like to make %(op_rd)s and %(op_wb)s check if they're
> accessing R15 and read/write the PC instead. Instructions that know
> they're going to write the PC (ignoring predication) would be
> instructed/constructed to set the "branch" bit (or whatever it's
> called). That's actually one of the reasons the instructions need to
> know when they're going to modify the PC. Does anyone have a
> suggestion
> for how something like that might work? I have some ideas, but they
> involve fairly dramatic changes to how ISAs are defined. I'd like to
> avoid getting sucked into something like that right now if possible,
> although I wouldn't necessarily mind.
>
> Gabe
> _______________________________________________
> m5-dev mailing list
> [email protected] <mailto:[email protected]>
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
