Killermike, the “API Layer” I propose IS a Virtual Machine. Some people spotted a couple of technical problems with your proposal, and this is intended to overcome those problems. My proposal is a fairly simple concept: Any program making a call to the OS uses an SWI instruction. The OS contains a decoding routine which generates an address from the SWI number. Changing that decode process to intercept calls that will cause compatibility problems and deal with the incompatibility, solves the problem. As far as the application is concerned, it is running on standard RISC OS, but the software on the other side of the API layer could be anything. There are some modules, such as BASIC and CLI which would have to be thought of as part of the API layer because applications are able to interface to them without SWIs. I don’t “think” there’s that much work to my proposal, but I can’t quantify it.
Like you, I don’t think a fully “multithreaded” OS is on the cards at this point, so the idea is to find a way to run two or more apps on additional cores. The software that sits under the API Layer can’t be RISC OS as we know it because it must include some multithreading just to schedule two or more cores.
I think you’re right about taking advantage of new graphics hardware, but if TI, Qualcomm and Freescale are all including graphics hardware on the chip, which one do you support?