On Tue, Aug 4, 2009 at 9:18 PM, Krishna, Tushar<[email protected]> wrote: > Hi, > There is a small bug in the initialization of DATA_MESSAGE_SIZE (which is > used by the Network). > > In src/mem/ruby/network/Network.hh > there is this line: > > const int DATA_MESSAGE_SIZE = (RubySystem::getBlockSizeBytes()+8); > > The problem is that RubySystem's init function (which sets the block size) > is called *after* Network is created, and hence DATA_MESSAGE_SIZE gets set > to (0 + 8). >
Good catch. > Network has its own init function too which is called later, but > DATA_MESSAGE_SIZE is not part of that. > > Brad and I were discussing some potential ways to solve this issue. > We can either make DATA_MESSAGE_SIZE a local variable of the Network class > and set it during the init. However, this leads to things like declaring > static variables, referencing the network pointer from the system pointer > etc -> a sort of ugly way to set a constant parameter. > I don't think it's that bad. For one, I'm not sure why it would have to be static. It could just be a standard member of Network. As for referencing the Network pointer from System, I don't think that's a problem, either. The system object has a pointer to all other objects anyway, and I don't believe that is going to change even as we go toward the M5-like configuration. In fact, I think the goal is to eventually remove all globals, System included, so Network and System would presumably have pointers to each other. The way to do it that would fit with the current Ruby configuration style would be to initialize an m_data_message_size member in init() based on a parameter passed in the argv vector. To do this you'll need to add a :data_message_size default_param to the Network class in defaults.rb, print it's value in Network::argv in cfg.rb, then consume the value in Network.cc::init. > Another possibility is using 64 bytes as the block size here and then having > an assertion check in the init function... Perhaps that would work for whatever it is you're currently working on, but definitely not a permanent fix. > > Any suggestions from the GEM5 team? > > Thanks > Tushar > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
