On Thu, 20 Oct 2011, nathan binkert wrote:
Let me paint the actual situation. Each coherence protocol in Ruby generates
a MachineType enum, and this varies depending on the protocol. This enum and
some of the functions defined on the enum are used in different parts of
Ruby. Currently, I see this enum to be the only blocking factor in compiling
different protocols together. I have not been able to find a good way to
make this enum private to the protocols. Any suggestions?
Ah. You just need to cast the enum variables to integers (or some
typedef), that would work. You could also use a union of the enums
and a typedef, but that's probably overkill.
I think what you are suggesting is that each protocol may have its own
private definition of MachineType and that if some function needs to use
the enum, we have an argument of type int instead of type MachineType.
That I will work in some cases, but I think not all cases will get
covered. Let's look at an example code. This code is from
src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc
NetDest personal_dest;
for (int m = 0; m < (int) MachineType_NUM; m++) {
if ((destID >= MachineType_base_number((MachineType) m)) &&
destID < MachineType_base_number((MachineType) (m+1))) {
// calculating the NetDest associated with this destID
personal_dest.clear();
personal_dest.add((MachineID) {(MachineType) m, (destID -
MachineType_base_number((MachineType) m))});
new_net_msg_ptr->getInternalDestination() = personal_dest;
break;
}
}
All the functions MachineType_* are defined by SLICC and just like the
enum, their definition depends on the protocol under consideration. To me
it seems like, unless we make these functions virtual, it may not be
possible to dynamically associate them with functions defined by a
protocol. What do you think?
Thank
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
