I think there was a combination of things that lead to my confusion about M5 static data. One was definitely the timing.cc bug. I also when I was trying to get ruby memory to supply M5 cpus/devices memory, the use of stack data for functional access confused me. I knew that my dynamic data patch was not the right way to do it. Thanks for the clarification.
Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Reinhardt Sent: Thursday, March 18, 2010 9:30 PM To: M5 Developer List Subject: Re: [m5-dev] [PATCH 00 of 31] Ruby updates and simple perf. optimizations On Thu, Mar 18, 2010 at 7:00 PM, Beckmann, Brad <[email protected]> wrote: > I appreciate all the feedback on my patches, but I never got a response to my > M5 dynamic data question. If you have the time, I would like to understand > under what criteria do M5 cpus and devices use static vs. dynamic data? Sorry about that... I made a mental note when I first read this email to come back and respond after I had looked at the patches, but I forgot. Nate's description is correct; the distinction between static and dynamic data is really only about whether the Packet destructor should call delete on the pointer or not. (Note that there's also a third case, dynamic array, which says to call "delete []" rather than just "delete".) That distinction should not be significant outside of the destructor, which is why there's no method to test that flag (and I hope once we solve your problem there still won't be that method). So it's totally up to the sender to decide whether it wants to dynamically allocate a buffer or not. It actually has almost nothing to do with stack vs. heap; in fact, it is always illegal to put a stack pointer in the data field of a packet when you call sendTiming(), because it's almost certain that the packet will live past the lifetime of the calling scope. As Nate says, the only time it's safe to use a stack buffer for the packet data pointer is if you're going to call sendAtomic() and not sendTiming(). In practice, for a timing-mode device, it typically depends on how many outstanding requests the CPU or device can have. If there's only a small, limited number (e.g., for the simple CPU models there's at most one load/store and one ifetch, or maybe just one overall) then typically the CPU/device will just statically allocate a data buffer for each possible outstanding request as part of the SimObject and then reuse that buffer to save the overhead of calling new & delete all the time. OTOH, if the CPU/device can have lots of outstanding requests such that it's too hard to manage a statically allocated set of buffers, then it will allocate them dynamically. So I'm left wondering what the bug is that you saw that led you down this path... Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
