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.
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? I'm going to start implementing this assuming there will be a copy. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
