Thanks for clarifying that the classic model already has crossbars and snoop filters. I was not aware of that.
As far as changing paths goes, I'm not claiming the effort to fix a single repository is high. However, there are *a lot* of people within AMD using gem5 and many customized versions of gem5 exist throughout the company. I would strong prefer not to have to communicate that everyone using gem5 needs to run a sed script before updating to the latest repo. While the script seems straightforward to you (Nilay and Andreas) there are many people who don't want to deal with these sort of complexities. In general, we have a lot of current users out there. We should do our best to avoid these sort of changes. Brad -----Original Message----- From: gem5-dev [mailto:[email protected]] On Behalf Of Nilay Vaish via gem5-dev Sent: Wednesday, November 12, 2014 6:01 AM To: Andreas Hansson via gem5-dev Subject: Re: [gem5-dev] Memory directory structure Brad, would not a couple of sed commands be enough for fixing paths in existing patches? I think we should let Andreas move slicc and protocol directory to ruby and he would provide a sed script that fixes everything. In fact, if we can, we should have things separated out into three directories: common (port stuff), classic and ruby. Common code can still reside in src/mem as it is currently. As far as the replicated components are concerned, I don't think it would be possible for one memory system to use what the other provides unless somebody is willing to make significant changes to at least one of the two systems. Note that classic does not understand ruby's messages and flits and ruby only partly understands what packets are. Therefore, Andreas can make an interconnect directory but that would contain only classic components for the time being. -- Nilay On Wed, 12 Nov 2014, Andreas Hansson via gem5-dev wrote: > Hi Brad, > > I suspected there would be issues lurking. Mostly the benefit would > be: 1) clarity for people not familiar with the code base, and 2) work > towards building the entire memory system independent of the ISA (and > put in a libmem.a or similar). If moving the directories is causing > significant problems on your side then we can hold off. > > I am not sure I understand your second point. The Œclassic¹ memory > system already has crossbars and snoop filters, I am merely suggesting > to not have a big flat src/mem directory, but create some structure. > Are you suggesting to put the Œclassic¹ components in src/mem/ruby? > > Andreas > > On 11/12/14, 12:06 AM, "Beckmann, Brad via gem5-dev" > <[email protected]> > wrote: > >> I understand that protocol and slicc directories are logically >> underneath Ruby, but I strongly content the small benefit of moving >> those directories does not justify the work it will create >> downstream. There is a lot of code that works on top of the current >> directory structure. I would really appreciate if we didn't make that >> change. >> >> Also Ruby already implements crossbars, snoop filters, and other >> interconnect/coherence structures. Why not just use those rather >> than add a new interconnect subdir? >> >> Brad >> >> >> >> -----Original Message----- >> From: gem5-dev [mailto:[email protected]] On Behalf Of Nilay >> Vaish via gem5-dev >> Sent: Tuesday, November 11, 2014 3:37 PM >> To: Andreas Hansson via gem5-dev >> Subject: Re: [gem5-dev] Memory directory structure >> >> I am fine with the proposed changes. >> >> -- >> Nilay >> >> On Tue, 11 Nov 2014, Andreas Hansson via gem5-dev wrote: >> >>> Hi all, >>> >>> I was contemplating adding a src/mem/ram subdirectory and put the >>> DRAM and SimpleMemory files there. >>> >>> I would also like to propose to move src/mem/protocol and >>> src/mem/slicc into the src/mem/ruby subdirectory as they are unique >>> to Ruby. Does that make sense? >>> >>> It might be worth creating a src/mem/interconnect subdir as well for >>> the crossbar, bridges, snoop filter etc. >>> >>> Thoughts? >>> >>> Andreas >>> >>> -- IMPORTANT NOTICE: The contents of this email and any attachments >>> are confidential and may also be privileged. If you are not the >>> intended recipient, please notify the sender immediately and do not >>> disclose the contents to any other person, use it for any purpose, >>> or store or copy the information in any medium. Thank you. >>> >>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>> Registered in England & Wales, Company No: 2557590 ARM Holdings plc, >>> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered >>> in England & Wales, Company No: 2548782 >>> _______________________________________________ >>> 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 >> > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 ARM Holdings plc, > Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in > England & Wales, Company No: 2548782 > > _______________________________________________ > 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
