> On Sept. 4, 2015, 11:34 p.m., Brad Beckmann wrote: > > So there has been a lot of discussion on this patch, including splitting > > the patch up, but I have not seen a new version of the patch reposted. > > > > Again I really dislike these patches which touch all the .sm files. The > > SLICC language should be stable...it is 16 years old! I support adding new > > SLICC features when needed, but I dislike breaking backwards compability. > > I feel that the work we do at AMD strives not to break backwards > > compability in the sm files. Changing all the sm files to remove three > > minor 2-line hacks does not seem like the right cost/benefit tradeoff. > > > > We just had one person on our team spend 2+ weeks conforming our protocols > > to Joel's MessageBuffer to SimObjects patch. We still have a lot of work > > to handle Nilay's Address to Addr patch. It is not as simple has just > > running a sed command across all of our protocol files. > > > > How about we conpromise. Can you hold off on checking in any more changes > > to SLICC, including this patch, until we check in our GPU model and > > associated protocol files? Then you can make these changes across all the > > available protocols. > > Nilay Vaish wrote: > I don't think we need to serialize this process. Since ultimately I have > to perform the merge, I would rather not wait for all of your patches to > get into the mainline. The current state of the repository can be the > base point using which AMD can post and get patches approved on the > reviewboard. As the patches are approved, I would merge them in my > pipeline of patches (on top of the current mainline) and push them to the > mainline at suitable time points.
Brad, is this arrangement acceptable? - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3002/#review7122 ----------------------------------------------------------- On Sept. 5, 2015, 12:50 a.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3002/ > ----------------------------------------------------------- > > (Updated Sept. 5, 2015, 12:50 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11084:ebc6489939d8 > --------------------------- > ruby: slicc: fix naming of variables > > The way SLICC compiler has been written, it was difficult to use a variable > that appears in the base class AbstractController without adding some special > code to the file src/mem/slicc/ast/ObjDeclAST.py. This eliminates the need > for > any such special code. The problem ultimately turned out to be the way SLICC > handles pointer and non-pointer variables. Till now, SLICC tried to handle > everything using pointers, unless some special rules were specified, as was > being done for three variables: version, machineID and clusterID. Now the Var > class will have a field that indicates whether a variable is pointer or not. > This field is used to differentiate between pointer variables and other > variables. Pointer-based variables are allocated in the init() function of > the > controller, as was the case before. Other variables now need not be pointer > based. Variables that need the constructor be called on them will now > necessarily be declared as pointers. The protocols currently in gem5 have > been > changed accordingly. > > > Diffs > ----- > > src/mem/slicc/symbols/Var.py 0bf16d951605 > src/mem/protocol/MOESI_CMP_token-dir.sm 0bf16d951605 > src/mem/protocol/MOESI_hammer-cache.sm 0bf16d951605 > src/mem/protocol/MOESI_hammer-dir.sm 0bf16d951605 > src/mem/slicc/ast/ActionDeclAST.py 0bf16d951605 > src/mem/slicc/ast/EnqueueStatementAST.py 0bf16d951605 > src/mem/slicc/ast/FormalParamAST.py 0bf16d951605 > src/mem/slicc/ast/InPortDeclAST.py 0bf16d951605 > src/mem/slicc/ast/LocalVariableAST.py 0bf16d951605 > src/mem/slicc/ast/ObjDeclAST.py 0bf16d951605 > src/mem/slicc/ast/OutPortDeclAST.py 0bf16d951605 > src/mem/slicc/ast/PeekStatementAST.py 0bf16d951605 > src/mem/slicc/symbols/StateMachine.py 0bf16d951605 > src/mem/slicc/symbols/Type.py 0bf16d951605 > src/mem/protocol/MOESI_CMP_token-L1cache.sm 0bf16d951605 > src/mem/protocol/MOESI_CMP_token-L2cache.sm 0bf16d951605 > src/mem/protocol/MOESI_CMP_directory-dma.sm 0bf16d951605 > src/mem/protocol/MOESI_CMP_directory-L2cache.sm 0bf16d951605 > src/mem/protocol/MOESI_CMP_directory-dir.sm 0bf16d951605 > src/mem/protocol/MI_example-dir.sm 0bf16d951605 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm 0bf16d951605 > src/mem/protocol/MESI_Two_Level-dir.sm 0bf16d951605 > src/mem/protocol/MI_example-cache.sm 0bf16d951605 > src/mem/protocol/MESI_Two_Level-L1cache.sm 0bf16d951605 > src/mem/protocol/MESI_Two_Level-L2cache.sm 0bf16d951605 > src/mem/protocol/MESI_Three_Level-L0cache.sm 0bf16d951605 > src/mem/protocol/MESI_Three_Level-L1cache.sm 0bf16d951605 > > Diff: http://reviews.gem5.org/r/3002/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
