RE: [Gems-users] about SLICC and Message Buffers

["Mike Marty" <mikem@xxxxxxxxxxx>]

Yes, in fact some of the hacks you suggest to SymbolTable.C are already
there.  However I emphasize that they are "hacks" and shouldn't really be
used.  If you look at the SLICC parser (parser.y), you will see the
following expressions that do what you are interested in:

// globally access a local chip component and call a method
    |  THIS DOT var '[' expr ']' DOT var DOT ident '(' expr_list ')' { $$ =
new ChipComponentAccessAST($3, $5, $8, $10, $12 ); }
// globally access a local chip component and access a data member 
    |  THIS DOT var '[' expr ']' DOT var DOT field { $$ = new
ChipComponentAccessAST($3, $5, $8, $10 ); }
// globally access a specified chip component and call a method
    |  CHIP '[' expr ']' DOT var '[' expr ']' DOT var DOT ident '('
expr_list ')' { $$ = new ChipComponentAccessAST($3, $6, $8, $11, $13, $15 );
}
// globally access a specified chip component and access a data member 
    |  CHIP '[' expr ']' DOT var '[' expr ']' DOT var DOT field { $$ = new
ChipComponentAccessAST($3, $6, $8, $11, $13 ); }


These use the ChipComponentAccessAST which uses a hack to the symbol table
to access objects globally.

This is definitely "unofficial" functionality and isn't fully tested.  It
does allow you to directly access an object in some other controller either
in your own Chip (Chip.C and Chip.h are generated files) or some other chip.

Another way is to simply add Ruby functions (say in RubySlicc_Util.sm and
RubySlicc_Util.h) that directly accesses objects by going through the global
system pointer (g_system_ptr).  This points to all the Chip classes which in
turn has all the objects.  

In either case, you would essentially be doing something that is not modeled
(like trying to access a centralized tag array for free).  It might be
better to use a SLICC controller and specify it in a custom network file.
Some network files are contained in ruby/network/simple/Network_Files.
These files specify links between different SLICC controllers.  The existing
files only contain Directory, L1Cache, and L2Cache controllers.  However you
can certainly add additional types of controllers.  Hence you can
encapsulate some object with a SLICC controller and keep it separate from
the memory interconnect, the L1Cache-L2Cache interconnect, and etc.  

--Mike



> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
> bounces@xxxxxxxxxxx] On Behalf Of Nauman Rafique
> Sent: Friday, March 04, 2005 3:29 PM
> To: Gems Users
> Subject: RE: [Gems-users] about SLICC and Message Buffers
> 
> I dont think I totally understand what "custom network file" means and how
> to go
> about it?
> Another approach could be to hack SymbolTable.C (and maybe parser and AST
> stuff)
> to make it possible to go without the network. What do you suggest?
> 
> Thanks.
> --
> Nauman
> 
> 
> Quoting Mike Marty <mikem@xxxxxxxxxxx>:
> 
> > MessageBuffers are used to communicate between SLICC controllers via
> > messages in the network.  If you want to use MessageBuffers to
> communicate
> > between other types of objects, you can certainly create a SLICC
> controller
> > (not used for cache coherence) to encapsulate your objects.  The SLICC
> > controller for this could use a single state that simply popped messages
> off
> > of the queue and did something.  You can also specify the links between
> > these controllers to be independent from the rest of the system by
> creating
> > a custom network file.
> >
> > A SLICC controller can have many types of objects that it directly
> interacts
> > with.  For example, MOESI_CMP_directory-L2cache.sm has a TBETable,
> > CacheMemory, and PerfectCacheMemory (to implement a directory).  You can
> add
> > your own user-defined types as well.
> >
> > Accessing an object located in some other SLICC controller is not easy
> and
> > we intended it to be that way.  However internally we have added some
> syntax
> > to the SLICC parser to "cheat" by directly accessing objects in other
> > controllers.  This functionality is not used in any of the examples and
> it
> > has only been used occasionally for some internal experiments.  If you
> are
> > interested in using this "cheating" interface or extending it for your
> own
> > purposes, I can give you some pointers.
> >
> > --Mike
> >
> >
> > > -----Original Message-----
> > > From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
> > > bounces@xxxxxxxxxxx] On Behalf Of Nauman Rafique
> > > Sent: Thursday, March 03, 2005 4:27 PM
> > > To: gems-users@xxxxxxxxxxx
> > > Subject: [Gems-users] about SLICC and Message Buffers
> > >
> > > I am looking at the SLICC protocol specification.
> > > I found that the message buffers are declared like this:
> > >  MessageBuffer responseFromDir, network="To", virtual_network="3",
> > > ordered="false";  // Dir -> mod-L2 bank
> > > Is this format strict i.e. mesage buffers can only be used to
> communicate
> > > to/from network (or they can be used to communicate with other objects
> > > too)?
> > > Moreover, as MessageBuffer is an external type, can we call the
> methods on
> > > it
> > > (the ones that are declared in MessageBuffer.h).
> > >
> > > Thanks
> > > --
> > > Nauman
> > >
> > >
> > > _______________________________________________
> > > Gems-users mailing list
> > > Gems-users@xxxxxxxxxxx
> > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >
> 
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users