Otherwise it seems good to me

src/mem/bus.hh (Diff revision 1)

Perhaps this would be better defined in the Bus class as to not pollute the global namespace?

Show all issues

1. Andreas Hansson Feb. 12, 2012, 2:46 a.m. (Feb. 12, 2012, 2:46 a.m.)

   That is what I initially wanted, but it is not allowed: ISO C++ forbids initialization of member. Both clang and gcc refuse. If anyone has a better way please let me know (and that does not include using enum or #define :).

2. Ali Saidi Feb. 12, 2012, 3:34 a.m. (Feb. 12, 2012, 3:34 a.m.)

   static const int16_t ... should do the trick.

Ship It!

Consensus to ship it?

src/mem/bus.cc (Diff revision 3)

This should really be fatal() rather than panic() (I know you were just copying the existing panic() but it's wrong too).

Also we could converge to a single fatal() path if the logic went like this:

if (useDefaultRange) {
    for (...) {
        return defaultPortId;
    }
} else if (defaultPortId != INVALID_PORT_ID) {
        return defaultPortId;
}


fatal(...);


It'd be good to work name() into the fatal string as well.

Show all issues

1. Andreas Hansson Feb. 22, 2012, 3:22 a.m. (Feb. 22, 2012, 3:22 a.m.)

   If we consider panic to be a user error and fatal to be an internal condition that should never happen, then surely this should remain a panic if a user miss-configures a bus, or issues addresses that do not exists. Do you not agree?
   
   I have changed the control flow as suggested.

src/mem/bus.cc (Diff revision 3)

I believe you have your definition of fatal and panic backwards.
http://www.gem5.org/Utility_Code#panic.2C_fatal.2C_warn.2C_inform.2C_hack:_which.3F

panic() should be called when something happens that should never ever happen regardless of what the user does (i.e., an actual m5 bug). panic() calls abort() which can dump core or enter the debugger.

fatal() should be called when the simulation cannot continue due to some condition that is the user's fault (bad configuration, invalid arguments, etc.) and not a simulator bug. fatal() calls exit(1), i.e., a "normal" exit with an error code.

1. Andreas Hansson Feb. 22, 2012, 7:34 a.m. (Feb. 22, 2012, 7:34 a.m.)

   Ok, thanks for the clarification. Sorted.
   

Ship It!