Fixed an RV32ec compiler regression, added optional per-subarch RISC-V rtl dirs

[MattBradford]

Also added a means of trimming the number of interrupt vectors allocated at compile time so that resource-constrained MCUs can use some of the dormant vector area for actual code.
The per subarch RTL search looks for a specific subarch folder in the RV32-embedded target.  If there isn't one, it reverts to the old flat single architecture folder for the RTL.  So each variant can have parallel RTLs.
The RV32EC subarch had a regression in the register allocator that broke RTL compiling for that target.

Do I need to do anything besides the pull request submittal on GitLab to push it into the main branch?

[ccrause]

Do I need to do anything besides the pull request submittal on GitLab to push it into the main branch?

This is basically how it is done.  If you want to you can also post on the fpc-devel mailing list to try and catch the attention of a core developer such as Florian or Jeppe.  Some effort should be going into finalizing the next compiler release, so it may take a while before a core developer reviews this contribution.

[MattBradford]

Well, I tried the mailing list route.  We'll see if that works.
There's a handful of RV32 codegen bug fixes in my next merge request after this one gets merged, so hopefully it gets processed in the near future.

[MattBradford]

Still not response even though a dozen or so other merge requests have been applied since.
Maybe there's something wrong with my MR wording or they don't trust newbies with the code or something.
I have another independent MR that slightly modifies the -ix FPC switch to enumerate installed cross compilers and place them in the machine readable report.  This is part of a MR I put into Lazarus to query the installed compiler for all available CPUs, environments, subarch, and -Wc microcontroller options.  That way it can query all the available options and fill in the dropdowns instead of relying on static tables in the IDE that can go stale.
We'll see if that goes through since it doesn't actually modify the compiler internals.

[ccrause]

Still not response even though a dozen or so other merge requests have been applied since.
Maybe there's something wrong with my MR wording or they don't trust newbies with the code or something.

Nothing wrong in principle with your MR AFAICS.  The delay in response is IMO due to the small core team size and the very broad range of topics/specialities required.  This MR can basically only be reviewed by Florian, I don't know of anyone else actively maintaining the code generator side for RISC-V.

I have another independent MR that slightly modifies the -ix FPC switch to enumerate installed cross compilers and place them in the machine readable report.  This is part of a MR I put into Lazarus to query the installed compiler for all available CPUs, environments, subarch, and -Wc microcontroller options.  That way it can query all the available options and fill in the dropdowns instead of relying on static tables in the IDE that can go stale.
We'll see if that goes through since it doesn't actually modify the compiler internals.

This is a nice feature, although currently only implemented by the development version of FPC.  But that is really where this feature is needed, to avoid waiting for bleeding edge updates on the FPC side to reflect on the Lazarus side.