That actually isn't required. Since the update only happens at commit
the instruction is non-speculative at that point in time.
Ali
On
Mon, 30 May 2011 19:12:50 -0700, Gabe Black wrote: You want to mark
them nonspeculative too. Generally speaking, you can't undo a
speculative update to a
I think that's -why- it's not written until commit, unless that
changed recently. The serialization support makes instructions wait
after decode, I think, until the serializing instruction commits.
Gabe
Quoting Ali Saidi sa...@umich.edu:
That actually isn't required. Since the update
It was changed maybe 6 months ago. All writes to misc registers are
always buffered until commit and then written when the instruction
becomes non-speculative. This is how the exception sticky flags work for
example. Otherwise every instruction that set one of these sticky flags
in ARM would
Korey is pretty much correct. The miscellaneous registers are read at any time,
but they're only written at commit. So if you're updating the state in some
way that effects future instructions the code that does the update must be
marked IsSerializeAfter which prevents any future instructions
You want to mark them nonspeculative too. Generally speaking, you can't
undo a speculative update to a miscreg.
Gabe
On 05/30/11 16:23, Ali Saidi wrote:
Korey is pretty much correct. The miscellaneous registers are read at
any time, but they're only written at commit. So if you're updating
On May 29, 2011, at 3:03 PM, Marc de Kruijf wrote:
I'm seeing all (or almost all) ARM floating point operations serializing on
the MISCREG_FPSCR_EXC register.
I don't believe this is the case, and looking at the code seems to confirm
that. Since it's a miscellaneous register,
On Sun, May 29, 2011 at 7:59 PM, Ali Saidi sa...@umich.edu wrote:
On May 29, 2011, at 3:03 PM, Marc de Kruijf wrote:
I'm seeing all (or almost all) ARM floating point operations serializing
on the MISCREG_FPSCR_EXC register.
I don't believe this is the case, and looking at the code seems
That would do it. Misc register in the o3 are always available to be read.
There is no dependency tracking with misc registers in the o3, so I don't think
it should matter. However, it would be good to fix the cases where FpscrExc and
FpscrQc are read unnecessarily. If you've got some time to
On Sun, May 29, 2011 at 10:06 PM, Ali Saidi sa...@umich.edu wrote:
That would do it. Misc register in the o3 are always available to be read.
There is no dependency tracking with misc registers in the o3, so I don't
think it should matter.
If you don't mind my asking, how is this made safe?
If you don't mind my asking, how is this made safe? Is it some form of
speculation?
Misc. registers refer to non-speculative system state, so any instruction
that is going to change these is typically marked with a Serializing or
IsNonSpeculative flag.
The CPU Models can then treat these type
10 matches
Mail list logo
