Gabe Black wrote: > Steve Reinhardt wrote: > >> On Sun, Oct 24, 2010 at 11:21 PM, Gabriel Michael Black >> <[email protected]> wrote: >> >> >>> If you have ISA X and it needs to set the PC in some weird way y, then you >>> need an method for Y on the PC object. You also need an operand Y that knows >>> how to use y to manage the PC. The ISA needs to be able to define that >>> operand type, or the parser needs to have it built in. The second is a bad >>> idea, I think. The first might work, but it makes the workings of the >>> description more elaborately obfuscate the end result. This also assumes >>> whatever you're doing can be parameterized one dimensionally. >>> >>> I think what you're proposing might work, but honestly I'm really tired of >>> this change. If we're going to add whole new features to the parser, lets do >>> that as a follow up. >>> >>> >> I didn't mean to imply that every PC-related update would have to be >> done via operands, or that major changes to the parser are justified. >> I just think that in the cases where we previously had simple >> statements like 'PC = foo' or 'NPC= bar', and we could keep those as >> is by redefining those existing operands, it seems to me that it would >> be preferable to do that. >> >> Steve >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > Looking through the patch to get an idea of what this might look like, a > significant flaw is apparent. Most of the instructions that modify the > PC do that relative to the current PC, and that means reading and then > writing the PC. writing the PC is a read modify write operation, but > we've already read the PC earlier. There was no direct mechanism to > describe an offset in the old syntax, so these have to be read in, > operated on, and then written out as three different steps. Also some > operations aren't just displacements, and with delay slots its not > constant which pc should be displaced when you have annulled delay > slots. ARM won't cooperate basically at all because you need to > read/write the thumb mode bit pretty frequently to see how to update the > PC, and the PC behaves differently depending on the circumstances which > would need different accessors. > > I think we could reclaim a lot of these cases by making the parser > smarter like I said and making it keep track of whether or not it's read > in the PCState structure already. Not being able to put a "." after the > PCS operand is another major inconvenience, but maybe we can work around > that too because the actual type is fixed and overrides don't make > sense. These are both doable modifications, but they're both non-trivial > and I'd rather not hold up this change any longer or complicate it any > more by implementing them now. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
Although even if we make "." work after the PCS operand, the parser won't know if we're reading or writing when we use the accessors. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
