> 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).
> 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?
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
