Hey everybody. The method Nate suggested to declare a reference counted
pointer without having to include the definition of it's target type
worked, as did putting the Fault type into sim/fault.hh instead of
base/types.hh. I realized while I was making this change that
sim/fault.hh and sim/faults.hh have nearly equivalent names but not
equivalent purposes, and it would be nice to differentiate them a
little. sim/fault.hh makes sense as a name since it defines the Fault
type, but I think for many of our other pointer types reference counting
or otherwise, we usually end them in Ptr. What do people think of
changing the Fault type to FaultPtr since it really is a pointer to a
Fault object and not a Fault object itself? I think the Fault name may
be left over from the time Fault was an enum. Then it would make sense
to rename sim/fault.hh to sim/faultptr.hh or sim/fault_ptr.hh or similar.

Also, while it's great to be able to declare a reference counted
pointer, it's still a little cumbersome and might be hard to maintain if
done everywhere it might be applicable (hence sim/fault.hh). What do you
think about separating out the other Ptr types (StaticInstPtr,
RequestPtr, PacketPtr, maybe others) into their own header files so they
can be included without pulling in all the other stuff?

Also also, we have a nullStaticInstPtr defined statically in the
StaticInst class, but reference counted pointers (and specifically
StaticInstPtrs) seem to often get set to NULL directly. This makes me
think either the assignments to NULL are wrong and should be using
nullStaticInstPtr, or nullStaticInstPtr isn't needed and can be
eliminated. I'm thinking it's likely the later. Does anyone disagree? Is
there some reason I'm not seeing to having this fancy NULL pointer?
Would anyone object to getting rid of it?

Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to