| Age | Commit message (Collapse) | Author |
|---|
|
The instruction representation is already encoded in the trace
protobuf, so there's no reason to encode a part of it again. This is
especially true since this supposedly generic code is extracting the
first 8 bits of the machInst, a totally arbitrary set of bits for most
ISAs. If certain bits within a machine instruction are actually
relevant, the consumer of the trace should be able to interpret the
instruction bytes which are already there and extract the same bits
within the context of whatever ISA they're appropriate for.
Change-Id: Idaebe6a110d7d4812c3d7c434582d5a9470bcec1
Reviewed-on: https://gem5-review.googlesource.com/9401
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Use this function to get the binary representation of the instruction
rather than referencing the ExtMachInst typed machInst member of the
StaticInst directly. ExtMachInst is an ISA specific type and can't
always be straightforwardly squished into a 32 bit integer.
Change-Id: Ic1f74d6d86eb779016677ae45c022939ce3e2b9f
Reviewed-on: https://gem5-review.googlesource.com/7563
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The DTRACE() macro tests both Trace::enabled and the specific flag. This
change uses the same administrative interface for enabling/disabling
tracing, but masks the SimpleFlags settings directly. This eliminates a
load for every DTRACE() test, e.g. DPRINTF.
|
|
Doesn't support x86 due to static instruction representation.
--HG--
rename : src/cpu/CPUTracers.py => src/cpu/InstPBTrace.py
|
