On Fri, Oct 21, 2011 at 10:01 AM, Nilay Vaish <[email protected]> wrote:
> 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?
>
In this particular case, it seems like there are probably better ways to do
this... for example, MachineType_base_number looks like it could be
implemented as an array rather than a function, or a single virtual function
could take care of mapping destID to the appropriate MachineType value.
Are you using virtual functions in other places to handle dynamic protocol
selection?
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
