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?
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
