So actually load instruction gets executed twice causing the assertion to
fail on the second time.
769413949: system.switch_cpus.iew.lsq.thread0: Doing memory access for
inst [sn:15059405] PC (0x810ed626=>0x810ed62a).(1=>2)
769413949: system.switch_cpus.iew.lsq.thread0:
Is there a way to get the macroop from the corresponding instruction
pointer?
On Wed, Sep 11, 2019 at 5:07 PM Pouya Fotouhi wrote:
> Hi Shehab,
>
> Can you please confirm what is the macroop that is issuing that load? I
> suspect it's one of the 128-bit instructions (maybe recently
Hi All,
I'm trying to understand how cda microop works. I can see it's defined as
"defineMicroStoreOp('Cda', 'Mem = 0;', mem_flags="Request::NO_ACCESS")".
And I see in simple and atomic CPUs that we check the data before we
execute the instruction in case of requests with NO_ACCESS flag set.
My
Hi Shehab,
Can you please confirm what is the macroop that is issuing that load? I
suspect it's one of the 128-bit instructions (maybe recently non-temporal
ones that I added) that are executed as two 64-bit loads, and possibly the
second one is failing due to the cda check that we do, and that
If you use --debug-flags=ExecAll,Decode and narrow down your trace to the
Ticks that you know the load is failing with --debug-start and --debug-end
you should be able to get that.
Best,
On Wed, Sep 11, 2019 at 2:15 PM Shehab Elsayed wrote:
> Is there a way to get the macroop from the
On Wed, Sep 11, 2019 at 2:03 AM Tom Ray wrote:
> Thanks a lot.
>
> Maybe next time, I should check the stackoverflow website before I ask
> question in here ?
>
>
No worries Tom, there isn't that much info out there anyways, try a quick
Google, but feel free to ask if you don't find quickly.
>
