On Sat, Jul 10, 2010 at 11:37 PM, Gabe Black <[email protected]> wrote: > In ARM's SIMD instruction set extension Neon, there are some > instructions which can load or store 3 of something, and that something > can be 1, 2, 4, or 8 bytes. To implement this properly, I'm planning to > add readBytes and writeBytes functions to the various ExecContexts which > would load/store some arbitrary (but practically bounded) number of > bytes without performing endian conversion. As a side benefit, this > should, I think, let us get rid of the twin data types in SPARC and the > various explicit template instantiations used to support them. I think > something like this came up for MIPS too, although I don't remember the > particulars.
How did we end up handling the MIPS instructions? I don't recall. > As I've been thinking about the best way to do this, I realized that the > alignment of the incoming data won't necessarily be appropriate, and so > you can't cast it blindly to whatever type you were really after. The > extra copy would be nice to avoid, so I was thinking maybe these > functions would take in the buffer to load/store which would have the > proper alignment, and that would make its way through the memory system. > I don't know what would happen to it, though, on its way. Would it be > deleted and reallocated at some point, spoiling the alignment again? The > initial data would have to be dynamically allocated to keep the static > inst static and since the stack frame would be deallocated between > initiateAcc and completeAcc. Would the call to "new" totally outweigh > the benefit of not copying? Any thoughts? You lost me in this paragraph... are you talking about alignment for the host system or the simulated system? What extra copy are you referring to? Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
