On Sun, Jul 11, 2010 at 11:25 PM, Gabe Black <gbl...@eecs.umich.edu> wrote: > > Lets say I'm trying to read 3 uint16_ts. If I take the data from the > packet and just case it to a uint16_t *, the host memory used as the > packet payload may not be 2 byte aligned. What I'd need to do to ensure > I can pass around and/or manipulate each uint16_t without hitting some > sort of problem on less lenient host architectures is to copy the > ambiguously aligned packet payload into an unambiguously aligned array > of uint16_ts first. What I was hoping might be possible is to send in a > uint16_t array as the payload to start with so that even though it ends > up being treated as a generic blob of bytes, when it comes back it has > the right alignment and can be used in place. I don't know if that'd > work out, though, and the more I think about it the more doubtful I am. > Although from what I remember having briefly looked at the read/write > functions that are already there, they do something like that. They do > the "new" inside the read/write, but readBytes/writeBytes would do it in > the instruction object.
Thanks for clarifying... I believe new is guaranteed to return memory that meets the system's strictest alignment constraints, so I don't think there should be any problem in just allocating a generic byte vector and casting it appropriately if you wanted to do that. Though some searching to verify my belief about new says you can get into trouble if your compiler/libraries don't agree with you on what the system's strictest alignment constraint is... though this looks like it's an issue only for 16-byte SSE alignment: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795 Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
