(Switching from reviewboard to email...) On Wed, Jun 22, 2011 at 11:03 AM, Nathan Binkert <[email protected]> wrote:
> On June 22nd, 2011, 10:23 a.m., *Steve Reinhardt* wrote: > > Can we keep the byte swapping in the read/write functions by passing in a > flag (like the ByteOrderDiffers flag in sim/byteswap.hh) that says whether > it's needed, then adding a switch on the data size to call the right > swap_byteNN function? Normally I might not suggest this, but it solves the > trace data problem, and if we're going to push the info in for that then we > might as well do all the byte swapping in one place. Also I expect that most > of the time the flag will be a compile-time constant false, so the > performance won't matter anyway. > > Without a template, you have no type information, so you'd have to add a > switch statement to get the correct swap. > > Yea, that's why I said "adding a switch" :-) I still don't understand why the read/write functions in base_dyn_inst need to be removed. They handle everything correctly as far as I can tell. The base_dyn_inst knows its Impl and as a result should know its own endianness. > > I also don't quite understand this issue with signed/unsigned types. Is the > type of Mem not necessarily the correct size? If so, then the byte swapping > can't work. If it is, then I don't understand why we should be getting rid > of the template versions of these functions which handle the byte swapping > and tracing for us. > > The problem (IIRC) is that as we add the ability to support more user-defined types to the ISA description language, the current model wants us to add a new set of read() and write() methods to each CPU model for each type. One approach is to narrow down to a smaller set of supported types for memory (uint*, int*, double) but that creates an asymmetry in the ISA. Since all of the per-CPU-model templates are just wrappers around readBytes/writeBytes anyway, it seemed expedient to just eliminate the middleman. One intermediate option is to maintain the templates, but find a way to make them global (perhaps with per-ISA extensions?) rather than per CPU model. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
