SpyderTL wrote:
I understand that to be cross-platform, you would need to recompile to the native hardware byte code. But I also said that this area is pretty well covered by the technologies that I mentioned above.
Just a thought, instead of supporting PE, ELF whatever, have you considered using
IB files? In theory you could simply cut out the native bytecode converter from LLVM and reuse that in your executer, but I have no clue how big project that would be (I'm not that familiar with LLVM source). But seems possible, and IB files are OS independent. I do not call this interpreter, because this is rather an executer that actually compiles the code into memory (with the other segments) and then it runs that. This also cuts out the need for PE/ELF etc., as it creates segments in memory from the IB file right away.
SpyderTL wrote:
What is missing is the ability to load the same compiled binary on any OS, or even from a boot loader, and execute it. With a hint or two from the loader, the exact same binary could run with no OS, under MS-DOS, as a Windows Console application, a Windows Desktop application, a Linux Desktop application, a Linux Console application, a Windows Phone, etc. (Either by writing a huge switch statement, or by abstracting the OS details away with a static library.)
You are perfectly right. Once you have converted the independent bytecode into native one, all you need is an interface to the underlying functions. A huge switch wouldn't be good imho, as it would be unmaintainable on the long run. Most existing solutions are aiming towards a library (one for each platform), with more or less success. If you think about it, BIOS and UEFI Run-Time are such libraries (with unique calling conventions, and more or less success providing a common abstract interface).
SpyderTL wrote:
I was just curious if anyone had tried this, or could think of any reason that it wouldn't work, not whether it was a good idea, or worth the effort or not.
Well, for Java there's
SanOS with exactly that goal (from the site: "was developed as part of an experiment on investigating the feasibility of running java server applications without a traditional operating system")
For WASM, there's
WASI to provide a platform independent interface (something that you would consider a static abstration library for each platform). But it is far from being finished, you'll have to wait a couple of years before you could call it mature. There's no minimalistic, boot-loader like implementation yet that I know of, but certainly doable just like SanOS, and it certainly can be done on UEFI.
Imho they are doing WASI the wrong way (but that's just imho). Instead of designing a simple and straightforward API towards the WASM code that hides away all the OS and hardware specific details (like libc does for BSDs and Linux for example), they are planning to create a system of incompatible modules. This will never work properly imho, there'll be always problems about missing and or conflicting modules with incompatible interfaces.
Cheers,
bzt