>This would be (sort of) considered a type of self-modifying code, right?
I think that's generally agreed to be true. The program inspects itself and changes its behavior as a result. Ryan Gambord <gambo...@oregonstate.edu> On Sun, Oct 25, 2020 at 4:54 PM Derrick.Greenspan < derrick.greens...@knights.ucf.edu> wrote: > [This email originated from outside of OSU. Use caution with links and > attachments.] > Thank you, understanding how that works in real processors is very useful, > as I'll ultimately be in charge of writing the code that does the same for > this alternative memory system I am porting over. > > Gem5 itself seems to have the L1 instruction cache snoop the data cache, > which I figured was inaccurate behavior, but seems to be a reasonable > tradeoff for the flexibility of having arbitrary levels of cache. I believe > Ruby handles things appropriately, however. > > Thanks so much for all your help, I really appreciate it! This would be > (sort of) considered a type of self-modifying code, right? > > All my best, > > *Derrick Greenspan **MSCS* > > ------------------------------ > *From:* Eliot Moss <m...@cs.umass.edu> > *Sent:* Sunday, October 25, 2020 7:44 PM > *To:* Derrick.Greenspan <derrick.greens...@knights.ucf.edu>; gem5 users > mailing list <gem5-users@gem5.org>; Gambord, Ryan < > gambo...@oregonstate.edu> > *Cc:* Yan Solihin <yan.soli...@ucf.edu>; Mark Heinrich < > heinr...@cs.ucf.edu>; Justin Gosselin <jpgosse...@knights.ucf.edu>; > Christopher Giles <stard...@gmail.com> > *Subject:* Re: [gem5-users] Re: Cache-line contains both instructions and > data? > > On 10/25/2020 7:26 PM, Derrick.Greenspan wrote: > > Thank you so much for that clarification! Glad to hear that this /is/ > appropriate behavior. So, just > > to double check, my understanding one more time; it sounds as if it is > appropriate for it to map to > > the same cacheline as well, correct? In an inclusive cache, the L1I > cache would then get the data > > from the L2 cache, correct? In an exclusive cache, would this mean that > the L1D cache invalidates > > its copy and the L1I cache then grabs it from memory? > > Mostly. In real processors, I and D cache are not usually coherent with > each other, because the > case is rare and it's too costly (you don't want I cache having to worry > about modifications). What > is done in practice is that modified instructions are cleaned from the L1D > cache (making sure the > modifications are out L2, etc.), invalidated in the L1I, and then the > processor adequate > synchronized to make sure those actions have happened. Then an > instruction reference will miss in > the I cache and fetch the modified data from the L2 cache (or memory). > Each processor architecture > will have specific requirements. I can't vouch for exactly how this is > handled in gem5 for any > specific processor. > > Best wishes - EM >
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
