Sorry for the delay in responding... every time I came around to it the overhead of reading through the accumulated thread seemed more and more imposing. Even after I've read through it all I'm sure I don't quite understand all the issues in detail, but I'll comment anyway.
I agree that trying to store the ucode ROM in some binary format and then decoding it on the fly doesn't make much sense. If we store the ucode directly as a set of StaticInsts (or other objects that generate specialized StaticInsts) then we've eliminated the machine-code-to-StaticInst translation anyway, so not being able to cache the resulting StaticInsts may not be a big deal. Perhaps we can extend the StaticInst class (or create a subclass) which has a specialize() virtual method that reads state out of the thread context to (potentially) generate a new StaticInst? On the other hand, in general the idea of StaticInst objects that aren't truly static bothers me... it would be nice if the StaticInst could truly be static, and then the specialized information could be read out of the thread context on demand, with something like a DynamicInst used to cache the specialized version as necessary (basically treating the specialization the way we handle register renaming.) The bad thing is that we'd then need DynamicInst objects even for SimpleCPU, which is a big change. I'm not really pushing anything specific, just voicing my concerns in case it triggers some ideas. Can we just use a bit in the micropc to indicate ROM mode vs combinational mode? I don't get Gabe's comment about micropc-relative branches... in what case would you have branches between the two modes other than the single absolute branch you need to go from combinational to ROM mode? Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
