Quoting Nilay Vaish <[email protected]>:
On Mon, 16 Jan 2012, Gabriel Michael Black wrote:
It's been a long time since I wrote this code, but I believe what's
supposed to happen is that the function that generates the microop
is supposed to take the current macroop (the JMP that caused this
to be executed in the first place), take its emulation environment
object which defines operand sizes, and use that to construct the
microop. If no macroop is passed in, then the environment defaults
to one with dummy values. That's necessary if you're entering the
microcode ROM because of something other than an instruction, like
because you got an interrupt. Some of the relevant code is here:
http://repo.gem5.org/gem5/file/f348cf78072c/src/arch/x86/isa/microops/base.isa
If this is giving you problems, the macroop is probably getting
lost somehow. Is this related to what you were asking about the
other day?
Well, earlier the CPU was not entering this ROM code since inRom was
not getting set. After setting inRom, wrip writes rip as 0x50, which
results in a general protection fault. If I set the dataSize to 2
for that microop, then the fault goes away. Looking at the values of
the registers, it seems to that dataSize should be at least. In the
same rom code , the data size is being set for some of the microops.
Should not these also use the emulation environment of the current
macroop?
Different microops are doing different things and need different
settings. The size of RIP written shouldn't be set to a constant, but
some other microops may need to work on registers at a particular
fixed width.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
