Hi folks. Something I've been working on for a while, and something which
has come up again in a different context as far as RISCV custom ISA
extensions, is having multiple ISA descriptions within the same build. I
was initially interested in this to allow multiple ISAs, for instance ARM
and X86, but it would be specifically useful in RISCV to allow any ISA
extensions to be defined using the infrastructure of the ISA parser but
separate so they could be optionally included, defined in EXTRAS, etc.
I've thought about this a bit, and, with the caveat that it's not very easy
to verify that these are everything, I think these are the two major
blockers which would prevent having two ISA descriptions, at least of the
RISCV flavor, in the build at the same time.
1. The parser always generates a decoder called ${ISA
namespace}::Decoder::decodeInst. There must be exactly one of these. We
could potentially get around this by defaulting to this name, but making
the name of the function/method configurable so subordinate descriptions
could make other decode functions/methods which are not wired into this
primary spot and are called in some other way.
2. There are some global maximum register count variables which are
accumulated by the parser and used in the base StaticInst class to declare
arrays. I have a patch series which gets rid of this which has been slowly
making its way through review. With no global maximum, there is no need for
the parser instances to coordinate.
https://gem5-review.googlesource.com/c/public/gem5/+/38389
I *think* with these two major issues dealt with, and with the parser
running in different directories for each description (to keep its
generated files from trampling each other), and by carefully managing
#includes between the descriptions so they have the same operands,
bitfields, etc, that this should work. As I said though, it's hard to
verify that there isn't some other snag I'm not thinking of which could
crop up if/when we try it.
Gabe
_______________________________________________
gem5-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
