Yes, I will prepare a patch and submit.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Great, I'm glad that fixed it for you. Could you please upload your fix so
other people can benefit from it too?
https://www.gem5.org/contributing
Gabe
On Mon, Jul 26, 2021 at 11:39 AM Mohit Gambhir via gem5-users <
gem5-users@gem5.org> wrote:
> Thanks for that workaround. Introducing
Thanks for that workaround. Introducing additional variables hiResult and
loResult for ProdHi and ProdLo and using the new variables always on RHS
resolves the issue for now.
Regards,
Mohit
___
gem5-users mailing list -- gem5-users@gem5.org
To
Yes, I haven't looked at the code itself, but that explanation seems very
plausible. The way the ISA parser works is basically if something is on the
left hand side of an =, then it's assumed to be a destination, and
otherwise it's a source. It bases its decision *purely* on text, with no
Hi Gabe,
I think your code has not yet made into stable/master branch. I see that in
develop branch INTREG_IMPLICIT is no longer there and is replaced by
INTREG_PRODHI and INTREG_PRODLO
However, I see that even in develop branch there are two classes that are
generated - Mul1s and
That sounds plausible. In general, when you write to a register in x86, you
may be doing a partial write where the old data in the register needs to be
preserved. For instance, if %rax has 0x0123456789abcdef in it, and you want
to write 0x1 to %al, then you need both the old value and the value
Hi Ayaz,
Thanks for your reply. You are right that they do get renamed and are assigned
a different destination physical register for each instruction. But, as you see
below, IMPLICIT(0) and IMPLICIT(1) are both source and destination for IMUL_R_R
instruction. So each instruction is still
Hi Mohit,
I wonder if the number of Physical register file entries is becoming a
bottleneck in the configuration you are using? Normally, I would expect
that 'ProdLo' and 'ProdHi' registers will be renamed to some physical
register and should not cause any dependency between two independent
