That is impressive that you got all the gem5-gpu code to stay within EXTRAS! Do you do any customized profiling in your protocols, or do you rely on simple gem5 statistics?
I agree that it would be great if we could dynamically extend an enumeration using EXTRAS. If we could dynamically modify the RubySlicc_interfaces.slicc file using scons EXTRAS, that would be a good start. Does anyone understand scons well enough to do something like that? Brad -----Original Message----- From: gem5-dev [mailto:[email protected]] On Behalf Of Jason Power via gem5-dev Sent: Thursday, December 04, 2014 11:28 AM To: gem5 Developer List; Nilay Vaish Subject: Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static MachineType Hi Nilay, Brad, I don't love this solution to the MachineType problem. By specifying all of the machine types statically in the gem5 source, it makes it so the protocols we use in gem5-gpu must modify files in gem5 to work. As it currently is implemented, on the Ruby side at least, all of the gem5-gpu code can stay in EXTRAS, which I think is a good design. For instance our protocols have both an L1Cache and a GPUL1Cache which are separate machine types. With this patch, we will have to modify src/mem/protocol/RubySlicc_Exports.sm to get our protocols to compile. Maybe there's a way to dynamically extend this enumeration to include other machine types defined in the *.sm files of the protocol? Or maybe I am missing something in this patch? Thanks, Jason On Thu Dec 04 2014 at 12:17:11 PM Nilay Vaish via gem5-dev < [email protected]> wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2551/ > ----------------------------------------------------------- > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10594:b25131489b95 > --------------------------- > ruby: slicc: have a static MachineType This patch moves from a > dynamically defined MachineType to a statically defined one. The need > for this patch was felt since a dynamically defined type prevents us > from having types for which no machine definition may exist. > > The following changes have been made: > i. each machine definition now uses a type from the MachineType > enumeration instead of any random identifier. This required changing > the grammar and the *.sm files. > > ii. MachineType enumeration defined statically in RubySlicc_Exports.sm. > > > Diffs > ----- > > src/mem/protocol/MESI_Two_Level-L1cache.sm fea29fc045ee > src/mem/protocol/MESI_Two_Level-L2cache.sm fea29fc045ee > src/mem/protocol/MESI_Two_Level-dir.sm fea29fc045ee > src/mem/protocol/MESI_Two_Level-dma.sm fea29fc045ee > src/mem/protocol/RubySlicc_Exports.sm fea29fc045ee > src/mem/slicc/ast/DeclListAST.py fea29fc045ee > src/mem/slicc/ast/MachineAST.py fea29fc045ee > src/mem/slicc/parser.py fea29fc045ee > src/mem/slicc/symbols/SymbolTable.py fea29fc045ee > src/mem/slicc/symbols/Type.py fea29fc045ee > > Diff: http://reviews.gem5.org/r/2551/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
