There have already been discussions about this stuff, but I don't
think we're all on the same page so I'll summarize.
I want to allow the parser to support arbitrary types for operands so
that you can, for instance, use bitunions for registers with bitfields
in them, or structures for SIMD registers, etc. That makes the fixed
fields that define the number of bits in a memory type or whether it's
integer or floating point at best poorly defined and at worst entirely
undefined. The parser has no generic way to understand that sort of
thing.
What had been happening is that the ISA descriptions would use the
mem_acc_size substitution to set up a uint*_t that was the right size
for whatever they were loading and then use that. There were templated
versions of the read and write functions which were instantiated for
each of the uint*_ts and some twin types added for SPARC. If the
memory types were used directly, as they now had to be, the the right
types weren't instantiated explicitly and the linker would barf. This
was worked around by adding casts in the ISA description, but Steve
didn't like those. We talked about it, and Steve suggested something
along the lines of this new approach, specifically getting rid of the
templated read and write functions since they were problematic and not
technically necessary in the first place.
The functions with the switch statements in x86 were necessary because
they were written at a time before readBytes and writeBytes, and the
actual size of the access wasn't decided at compile time, it was
decided at run time based on the context the instruction runs in
(yeah, x86 is like that). They were necessary when readBytes and
writeBytes didn't exist, not revisited but still nice to have when it
did, and not useful once readBytes and writeBytes became the only
memory accessors.
These changes are to eliminate read and write entirely. Leaving them
in one place or the other is not useful since they aren't used by
anything and would at best be a useless inconsistency across different
implementations of a common interface.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
