So do you have any ideas for how to handle this? Sorry for pestering you if you're still traveling.
Gabe Gabriel Michael Black wrote: > Quoting Steve Reinhardt <ste...@gmail.com>: > > >> 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 <gbl...@eecs.umich.edu> 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 > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
