Quoting Steve Reinhardt <[email protected]>: > Sorry for the slow reply... I'm traveling this week.
Likewise, although I don't have a good excuse. > > On Sun, Jun 21, 2009 at 10:30 AM, Gabe Black <[email protected]> wrote: > >> 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. > > > I don't understand what you mean. Originally I was thinking that if the instruction implemented the "specialness" of R15 would help when trying to make an instruction be a branch or a nonbranch depending on what registers it wrote to. That doesn't quite make sense and isn't really true, and I just threw that into my earlier email without thinking about it as much as I should have. > > >> A better reason is >> that there is no register file object in anything but the simple CPUs. > > > I agree that it should not be in the reg file object. I think we're just > discussing the right way to get it out and put it in the decoder. Yes. > > >> My working solution so far is to annotate each instruction definition >> with a list of sources that might be the PC in disguise. > > > Is there really a list and not just a single register value? There are several possible source registers, potentially as many as 3 (or 4? I forget). These are the Rn, Rm, Rs and I think sometimes Rd for stores, although that might not be right. It may also be possible to have multiple different ways to write to the PC since there are loads/stores that update their base register. > > Also, is it the case that you can write the PC with any opcode? I vaguely > recall hearing that that was deprecated at some point. > I don't know. I saw some places in the ARM manual where it said some uses of R15 cause undefined behavior. I don't know where to find a concise description of where it is and isn't allowed. >> >> 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); >> > > Is this what you'd like to bury inside the op_rd/op_wr code? Yes, something like that. It might not be quite right (I think I missed a "+ 8" in the reading code), but it would have the nice property of knowing which operand index to use, not doing unecessary calls into the exec context, and also not confusing the parser about sources and destinations. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
