----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2988/#review6821 -----------------------------------------------------------
I'm surprised you moved forward on this patch. I thought I had communicated over email a few weeks ago that we should not go down this path before a lot of careful thought and debate on whether this is a good thing to do. Personally I think this patch removes many of the benefits of having a SLICC ast and goes against many of the main design principles of SLICC. SLICC is designed to avoid having the programmer worry about memory management. SLICC is a layered development approach where the sm file is only meant to considering the protocol logic. I believe that is why SLICC has been so successful over the past 16+ years. It allows one to create differnet protocols without requiring one to write C++ and handle complicated memory management. This patch removes those benefits. Please do not check this in. We need to come to a consensus on whether this is even a good direction to go in first. - Brad Beckmann On July 24, 2015, 4:45 a.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2988/ > ----------------------------------------------------------- > > (Updated July 24, 2015, 4:45 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10951:6cc98e435866 > --------------------------- > ruby: slicc: have c++ code in action blocks > > This patch changes the way code in action blocks is specified. Right now > we write SLICC code in action blocks, this patch proposes to have c++ code > instead. This is required for moving away from reference counted messages > currently in use by the ruby memory system. Also, from a longer term > perspective, this is required for writing a coherence protocol for the classic > memory system since most of the code for the protocol would be sourced > from the current c++ code in the classic memory system. > > > Diffs > ----- > > src/mem/protocol/MESI_Two_Level-L1cache.sm 9689ead7b479 > src/mem/protocol/MESI_Two_Level-L2cache.sm 9689ead7b479 > src/mem/protocol/MESI_Two_Level-dir.sm 9689ead7b479 > src/mem/protocol/MESI_Two_Level-dma.sm 9689ead7b479 > src/mem/slicc/ast/ActionDeclAST.py 9689ead7b479 > src/mem/slicc/parser.py 9689ead7b479 > src/mem/slicc/symbols/Action.py 9689ead7b479 > src/mem/slicc/symbols/StateMachine.py 9689ead7b479 > src/mem/slicc/symbols/Transition.py 9689ead7b479 > > Diff: http://reviews.gem5.org/r/2988/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
