xtensa: support for more than 32 interrupts

[williamtcdns]

This change add support for using more than 32 interrupts.

[andyross]

Cool, I wasn't aware of this evolution. Seems straightforward; looks like it's just "there are now four register sets to poll at ISR time with the same semantics as the old ones"?

Note that the assumption of 32 hardware interrupts is baked into some of the various SOCs already though, so they won't be able to support this without a little work. But then most of those interrupt controllers tend (sigh) to need new drivers every hardware generation anyway.

Also, and it's not the fault of this PR, but our handler architecture for Xtensa was never great and is really showing its age at this point. The generated C handler thing seemed clever early on but turns out not to generate very good code, and (as you discovered by having to 4x it here) there's a ton of senseless cut/paste going on.

[williamtcdns]

Cool, I wasn't aware of this evolution. Seems straightforward; looks like it's just "there are now four register sets to poll at ISR time with the same semantics as the old ones"?

Correct. Full description can also be found in following section of the Xtensa Instruction Set Architecture (ISA) Reference Manual:
4.4.9 Extended Number of Interrupts Option

[williamtcdns]

Please, how to resolve following twister failure at the Print cloud service information step ? it seems un-related to this PR change:

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
24.4% Duplication on New Code

See analysis details on SonarQube Cloud

[williamtcdns]

I rebased this PR change. Now the twister failures are all about kernel.timer test failing with following error un-related to this PR change: Assertion failed at WEST_TOPDIR/zephyr/tests/kernel/timer/timer_api/src/main.c:763: timer_api_test_timeout_abs: Z_IS_TIMEOUT_RELATIVE(t2) is false.

I will monitor the changes for that test and rebase again.