Hey folks, just FYI, the second of these two blockers has now been cleared, so we are closer to being able to cleanly and conditionally allow RISCV (or other ISA) extensions. Now it *should* just be a matter of making the decode function name configurable, and making the ISA parser available cleanly from things in EXTRAS (if it isn't already?).
Gabe On Wed, Jan 13, 2021 at 7:35 PM Gabe Black <[email protected]> wrote: > 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
