On 06/22/11 11:59, nathan binkert wrote: >> Yea, that's why I said "adding a switch" :-) > I guess I should read more carefully. > >> 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. > We only have a single template (like the one in base_dyn_inst), right? > Or is it swap_byte that are the issue? (there is a catchall version > of swap_byte (which could be done without a switch actually).
It's not really a catch all in a strict sense. It's still templated so you have to have a type, and the idea is that the switch gets optimized out. It should be able to handle an arbitrary but particular type of one of the supported sizes that gets swapped like an integer of that size. >> Since all of the per-CPU-model templates are just wrappers around >> readBytes/writeBytes anyway, it seemed expedient to just eliminate the >> middleman. > I guess, except that the should do everything we need, no? The switch > is more cumbersome imho. Also, how would the switch not end up in > each execution context? > >> 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. > > > Perhaps I'm still missing something and perhaps it's fundamental. > Everything we're talking about seems to revolve around the lines that > look like this, right? > fault = xc->write((uint%(mem_acc_size)d_t&)Mem, EA, memAccessFlags, NULL); > > To me, the problem seems to be that the type of Mem isn't properly > handled by read/write and so it must be cast. My main question, is > why is this cast necessary? What do these types look like? And how > is it that htog would do the correct thing with them while read/write > cannot be made to do the correct thing? htog is in a header file and read/write aren't (all). > Perhaps it's worth being on the phone. (I also wish these two diffs > were merged since they're so interrelated.) I can also shut up if you > guys are sure that you understand what is going on. My suspicion is > that there is something going wrong here, but I could simply be wrong > about that. > > Nate > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
