I guess it was too good to be true. When I actually -used- StaticInstPtr by itself, gcc didn't like passing an incomplete type by value.
Gabe Black wrote: > In the process of implementing this, I wound up creating an include loop > between static_inst.hh and sim/faults.hh. All I really needed was > StaticInstPtr, so it seemed silly that this didn't work. I remember > having a similar problem with PacketPtr, I think. Anyway, I have a patch > where I separate out StaticInstPtr into it's own header file. In the > process I merged together StaticInst and StaticInstBase since the > division doesn't really buy anything as of today. There were some > dependencies between StaticInst and StaticInstPtr that weren't > maintainable if they were in separate files, specifically the > StaticInstPtr constructor that called StaticInst::decode, and the > conversion constructor that went down to a StaticInstBasePtr (also I > nuked StaticInstBase). I'm pretty sure I fixed up all the places that > were using the StaticInst::decode constructor except probably in the > checker and ozone CPUs, and the change is very negligable. I'm still in > the process of making this change and making sure everything still > works, but since it touches a pretty fundamental area of the simulator > and does have some small cost I wanted to give people maximum chance to > discuss it. > > This sort of change might be handy to replicate for the other *Ptr > classes we have to cut down on unnecessary recompilation, the potential > for dependency loops, and total compile time. > > Gabe > > Gabe Black wrote: > >> Yeah, that seems pretty reasonable. Faults aren't a hot enough path for >> an extra, usually unused parameter to matter. If we make it default to >> Null that would probably save some editting and make things like >> interrupts (where the inst doesn't make sense) look a little more >> natural. I'll try that at some point here. >> >> Gabe >> >> Steve Reinhardt wrote: >> >> >>> What about just passing the StaticInst (if applicable, i.e., on any >>> synchronous fault) to Fault::invoke()? I'm not sure where all it gets >>> called from, but I'd expect it would be available at those call sites. >>> It'd be a big search-and-replace to fix all the function signatures, >>> but it would save having to squirrel it away in the thread context w/o >>> changing the control flow. >>> >>> Steve >>> >>> _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
