You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While some drmemtrace tools such as reuse_distance or functional cache simulators like
drcachesim are happy with the memory fetch as the record unit in our traces,
microarchitectural simulators prefer to see one instruction record with all
the data elements belonging to that instruction combined inside that
record, along with the next PC. Today, simulators have their own layer which creates this by reading
ahead to the next instruction record (to get the next PC) and combining all
the intervening data records into one instruction structure. This has the
downside of each simulator having to repeat this, and some issues with
having already fetched that next PC requiring a rollback if a speculative
path is launched and then the main trace is resumed at that next PC.
This is a feature request to possibly provide an output stream iterator
over instruction units: stream->next_instruction().
For marker records: probably it would throw them away; or it could append
them to the next instruction record. What about markers indicating
kernel-mediated PC discontinuities?
For the format: It is not worth trying to make a trace instr format also be
the simulator instr format as each simulator has its own state and is going
to need to convert to that anyway, so a simple structure is best.
Probably we would just do a vector of memref_t or more likely a simple
class with accessors for the data operands.
The text was updated successfully, but these errors were encountered:
While some drmemtrace tools such as reuse_distance or functional cache simulators like
drcachesim are happy with the memory fetch as the record unit in our traces,
microarchitectural simulators prefer to see one instruction record with all
the data elements belonging to that instruction combined inside that
record, along with the next PC. Today, simulators have their own layer which creates this by reading
ahead to the next instruction record (to get the next PC) and combining all
the intervening data records into one instruction structure. This has the
downside of each simulator having to repeat this, and some issues with
having already fetched that next PC requiring a rollback if a speculative
path is launched and then the main trace is resumed at that next PC.
This is a feature request to possibly provide an output stream iterator
over instruction units: stream->next_instruction().
For marker records: probably it would throw them away; or it could append
them to the next instruction record. What about markers indicating
kernel-mediated PC discontinuities?
For the format: It is not worth trying to make a trace instr format also be
the simulator instr format as each simulator has its own state and is going
to need to convert to that anyway, so a simple structure is best.
Probably we would just do a vector of memref_t or more likely a simple
class with accessors for the data operands.
The text was updated successfully, but these errors were encountered: