> I think that this is pretty elegant and won't confuse people unfamiliar
> with the initialization. As far as Nate's idea goes, I would want to see
> concrete cases where that is useful. It seems to increase
> complexity/confusing code and I don't know what it buys us. Flexibility is
> great, but flexibility without justification isn't.
It basically buys the ability to split initialization of a group of
objects into multiple phases. init() and startup() currently look
like this:
void init();
void startup();
They'd change to this:
bool init(int phase);
bool startup(int phase);
Most instances of these functions would just return false indicating
that they don't need another phase of initialization. In cases where
coordination is needed (I think that the CPUs, ThreadContexts and the
System in FS mode do some of this stuff in a somewhat convoluted way
by using startup() instead of init()), the function would return true
after phase 0 and false after phase 1. Something like this:
bool
init(int phase)
{
switch (phase) {
case 0:
// do phase zero initialization
return true;
case 1:
// do phase one initialization
return false;
default:
panic("this should never happen");
}
}
startup() was really intended for things like creating the tick event
when simulation started. It now does the double duty of that + doing
second stage initialization. I also don't believe that it is all that
complicated and could easily be documented in sim_object.hh and/or the
wiki.
Nate
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
