How does this compare to Erlang? Or, to be precise, and Erlang VM running on a contemporary OS.
I always had the feeling that the Erlang VM should have been implemented on the OS level from the start, and now it turns out some company actually did it (or something very similar)...
The only related tech I know of is Inferno, the OS developed later from Plan 9: binaries are platform-independent and run natively on all supported CPU architectures.
Android is a Linux. Native binaries are definitely possible.
Windows Phone 7.x was CE, 8.x was NT. Native binaries are the default.
IBM i: the OS isn't native on the hardware, but the abstraction layer is below the OS. (Taos made it part of the file loader, roughly.)
MCP: I don't know enough to judge. I believe that they run on x86 today via a mainframe CPU emulator, though.
UCSD p-System: contained a bytecode interpreter; no native compilation possible, but of course every other version of the language did, leading to the p-System's extinction.
Modula-2, Oberon: by default, compile to native executable binaries.
A cross-platform format, SLIM, was proposed for Oberon but I am not sure it was ever implemented, let alone included as standard.
Or are you thinking of ORP, the Oberon-to-RISC Parser? Is that not just part of the compiler?
Xerox PARC: what did you have in mind? AFAIK, Alto, Star, Dandelion, etc. all had native binary formats -- more than one for each model, in fact, depending on the OS loaded onto it.
> Android is a Linux. Native binaries are definitely possible.
Android uses the Linux kernel, tranparently!
Officially only native shared libraries are allowed by non-rooted devices.
> Windows Phone 7.x was CE, 8.x was NT. Native binaries are the default.
Windows Phone 7 only allowed .NET applications for common developers, C++ applications required a special license from Microsoft.
Windows Phone 8.x used MDIL (Machine Dependent IL), with a on-device linker at installation time.
Windows Phone 10 used MSIL as main package, and Windows Store does the job of AOT compiling that MSIL with a so called cloud compiler.
> IBM i: the OS isn't native on the hardware, but the abstraction layer is below the OS. (Taos made it part of the file loader, roughly.)
Doesn't matter, unless one is using Metal C, all applications use TIMI.
> MCP: I don't know enough to judge. I believe that they run on x86 today via a mainframe CPU emulator, though.
What matters is the orignal version.
> UCSD p-System: contained a bytecode interpreter; no native compilation possible, but of course every other version of the language did, leading to the p-System's extinction.
There were commercial systems using native compilation like Corvus Systems workstations.
> Modula-2, Oberon: by default, compile to native executable binaries.
Modula-2 was designed for Lillith and M-Code originally. Lillith uses bytecode with interpreter on microcored CPUs.
A cross-platform format, SLIM, was proposed for Oberon but I am not sure it was ever implemented, let alone included as standard.
Oberon System 3, nicely documented on its manual.
> Xerox PARC: what did you have in mind? AFAIK, Alto, Star, Dandelion, etc. all had native binary formats -- more than one for each model, in fact, depending on the OS loaded onto it.
Xerox PARC systems use bytecode formats, before booting the OS, a microcoded interpreter for the respective bytecode format is loaded into the CPU.
FWIW, you are my single most respected commenter on HN, and I often find that you've commented with what I would have wanted to say myself were I only a bit quicker.
But while this is very interesting and I am learning a lot from it, I do think you're stretching a point to breaking here.
> Here we go,
:-)
> Android uses the Linux kernel, tranparently!
>
> Officially only native shared libraries are allowed by non-rooted devices.
OK. I didn't know that.
> Windows Phone 7 only allowed .NET applications for common developers, C++ applications required a special license from Microsoft.
Interesting.
> Windows Phone 8.x used MDIL (Machine Dependent IL), with a on-device linker at installation time.
OK. Both only ran on Arm32, though, didn't they? So, not native, true, but also not cross-platform binaries?
> Windows Phone 10 used MSIL as main package, and Windows Store does the job of AOT compiling that MSIL with a so called cloud compiler.
Again, fascinating stuff. Still Arm-only, though, right?
> Doesn't matter, unless one is using Metal C, all applications use TIMI.
I submit that it does.
I was saying that 2 OSes I knew of allow the same binaries to run on multiple different CPU architectures: Inferno and Taos/Intent/Elate. There are no native binaries and if you compile source to a binary, the result is inherently natively cross-plaform.
These examples are all fascinating but they are examples of a different phenomenon: where the OS does not allow or does not have native object code for the metal underneath, the only permitted binaries are in some abstract form or for some abstract architecture...
But if the OSes only ran on one arch, then the cross-platform part of the equation is missing.
> What matters is the orignal version.
Did MCP run on >1 native CPU arch?
> There were commercial systems using native compilation like Corvus Systems workstations.
Did the resultant binaries run on different platforms, though?
> Modula-2 was designed for Lillith and M-Code originally.
Originally, maybe, but that is not where it enjoyed mainstream success. I first encountered it as Topspeed Modula-2, the fastest compiler of any kind for the original IBM PC and compatibles.
> Lillith uses bytecode with interpreter on microcored CPUs.
Bitsliced, weren't they?
Anyway, I did not know that. I'd argue that in all other implementations it was just a natively-compiled language like Pascal before it.
> Oberon System 3, nicely documented on its manual.
I will read up on that. I see someone's added it to the Wikipedia page since I did quite a bit of work on that.
> Xerox PARC systems use bytecode formats, before booting the OS, a microcoded interpreter for the respective bytecode format is loaded into the CPU.
I always had the feeling that the Erlang VM should have been implemented on the OS level from the start, and now it turns out some company actually did it (or something very similar)...