CLib issues
- Works for the most part under StrongARM emulation if I let CallASWI's through to the OS, Populous for example runs okay. On physical SA however this wont work as SWI's that require managed entries aren't supported (see CallASWI issues)
- CLib makes extensive use of CallASWI (partly coded)
- _kernel_osfile needs hypervising (coded by untested)
- On the Pi there's odd behaviour. The Abort vectors are being entered in User mode, causing ADFFS to crash when it tries to perform TLB and cache operations
- C code of yore makes use of code self-modification. Codelets from modified code aren't currently reused, so eventually the codelet space is exhausted. The codelet generator needs to track freed codelet space and reuse it
- SWI's that require codelets aren't supported, so any kind of vector claim or Sound_Configure/Sound_InstallVoice for example will cause ADFFS to abort the process. The problem here is that the entry points associated with the SWI are within the codelet, which is tied to the SWI instruction. In the case of CallASWI this can't happen as it could be calling various SWI's, so the codelet in effect dynamically changes. Either vector entry points need recoding so they're not associated with a codelet, or a dummy codelet needs creating (coded for vectors using dummy codelets)
- SWI's that require hypervising need changing on route to CallASWI, so they come back to the hypervised SWI handler (coded)
- Needs to confirm the SWI issuer is within code created by the JIT or in the case of CLib calls, that the CLib caller is code created by the JIT
- FPU instructions aren't covered by the JIT - Quest for Gold is causing Floating Point Exceptions
