On Mon, Aug 3, 2009 at 3:53 PM, Beckmann, Brad<[email protected]> wrote:
> I was hoping that there was a better way to solve this...I'm glad you found
> it! However I'm confused why you don't think "MachineType::L1Cache" is legal
> SLICC code? SLICC can reference a particular machine type by simply removing
> a colon, "MachineType:L1Cache". This will translate to "MachineType_L1Cache"
> in the generated code.
Well then, problem solved!
Simple broadcasts in systems with little hierarchy can use this
broadcast function without too much complexity. However, systems with
more hierarchy will require a more comprehensive solution. For
example, if you want to broadcast only to those L2 caches that are
within you same chip. I know you recently changed the configuration
infrastructure to support heterogeneity and I'm not quite clear how
the new configuration infrastructure specifies hierarchy in the
ruby-language files. Could you elaborate or point me to an example?
It would be great if we could get the new configuration infrastructure
to generate functions such as: "NetDest getLocalL2Caches(MachineID
machID)". That is what I was trying to get at with adding a hack to
slicc/symbols/Type.cc.
I see. Unfortunately this isn't possible at the moment. In the new
configuration, there really isn't any notion of "local" because there
is no longer a generated chip object. Now Ruby (network included)
doesn't care where a controller is located and treats them all the
same. You configure a multi-chip system by just adjusting latencies
to reflect off-chip communication.
This of course complicates finding on-chip components. Here's one
idea of how to fix this that follows the "keep it generic" philosophy:
1. Create a Chip class that basically just contains pointers to
AbstractControllers, e.g.,
class Chip {
public:
void addController(AbstractController* c) { ... }
void getControllers(MachineType type) { ... }
private:
Vector* m_controllers = new Vector[MachineType_NUM];
}
2. Also add a getChip() function to AbstractController.
3. Then add a function in RubySlicc_ComponentMapping called
getLocalBroadcast(AbstractController*, MachineType). You'll need the
ability to reference "this" in SLICC, which I don't think you can
currently do.
4. Modify the generated Controller init functions and add lines like:
m_chip = RubySystem::getChip(m_cfg["chip"]);
m_chip->addController(this);
5. Here's the only tricky part - you'll need to add chips to the
Ruby-lang configuration. This will involve adding a new attribute to
NetPort called chip, adding a chip argument to all NetPort subclasses,
and printing out the actual chip configuration.
Thoughts? If you like this approach I can help you navigate through
the configuration changes.
>
> Thanks,
>
> Brad
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Derek Hower
> Sent: Monday, August 03, 2009 11:17 AM
> To: M5 Developer List
> Subject: Re: [m5-dev] Fwd: GEM5 Issues
>
>
>>
>> - NetDest support in RubySlicc_ComponentMapping.hh
>>
>> The functionality I'm particularly concerned about is setting the
>> destination of a message so that it broadcasts to all L1 caches or all
>> directories. Before, all of those helper functions were in
>> RubySlicc_ComponentMapping.hh. If we don't want those helper functions on
>> the ruby slide any more, we could add them to the generated MachineType.cc
>> file by hacking the "if (m_isMachineType)" statement in
>> slicc/symbols/Type.cc. It wouldn't be the first hack added to that file or
>> the ugliest hack in SLICC. :) If you have a suggestion for a more elegant
>> solution, I'm happy to hear it.
>
> I think the right wat to do this would be to a broadcast(MachineType)
> method in RubySlicc_ComponenMapping.hh that looks like:
>
> NetDest broadcast(MachineType type) {
> NetDest dest
> for (int i=0; i<MachineType_base_count(type); i++) {
> dest.add(MachineID(type, i));
> }
> return dest;
> }
>
> Then in SLICC have a line that looks like:
>
> out_msg.Destination := broadcast(MachineType::L1Cache);
>
> The problem is that MachineType::L1Cache is not legal SLICC code.
> Adding this would require a change to parser as well as the code
> generator. It would be a bit of work, and the question is, is it
> worth it to make this fix given that SLICCer will (eventually) happen?
> I'm not sure.
>
> Perhaps a comprimise between right and fast would be to pass something
> to broadcast that SLICC does know about. For example, you could pass
> a string to broadcast and then use string_to_MachineType to get the
> MachineType. Obviously, this is slow and you probably don't want to
> do it, but something similar could work. (use
> MachineType_from_base_level?).
>
> Other ideas?
>
>
> _______________________________________________
> 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
