Hacker News Reader

Comment by MiroslavPokorny | Hacker News Reader

CPU architectures evolve and often get replaces, eg Mac has moved from 68k -> Power -> x86 -> ARM or even Windows PC have also jumped from 32 to 64 bits and the same is also true of SIMD.

Why dont O/S support executables with something like LLVM binaries and generate the native code at load time ?

This would solve so many problems including the need for emulators, because all binaries would work on all CPUS, and the OS would produce the best code at load time.

No more cpu detection, vector stuff always works on the latest & widest instructions that are available. CPUs can also retired old legacy instructions without worry and more.

View on HN

This does exist, we call it Java (or C# or probably a dozen other implementations)

The big tradeoff you're making is that you have significantly less time to run your optimizer, since not everybody has a beefy machine or the patience to wait a day for their browser to start first time.

You could try doing optimization ahead of time, but I think (I could be wrong here) you would inevitably end up adding in some CPU assumptions if you went much further. This also somewhat conflicts with an advantage of VM based execution, that new optimizations apply to old binaries.

I'll also note that hand rolled assembly/SIMD code still beats compilers at the extreme end and you would either have to throw that away, or get all the disadvantages mentioned above without all the advantages

> significantly less time to run your optimizer,

Not necessarily, you work around this with JIT caches, which allow the optimiser not to start always from zero.

Additionally your can also AOT compile, with or without PGO data.

All modern bytecode implementations, at least for Java and .NET, use a mix of JIT with caching/AOT/PGO.

You can work around this in various ways yes (I'll add dynamic recompilation to your list of workarounds), but you're always going to have the problem of "Somebody downloaded a program and want to run it now"

Yeah, however in that very specific scenario it isn't about any winning SPEC benchmark suit.

Adding another workaround, shipping the JIT cache metadata alongside the program, and dynamically sharing it across all devices of the same category, as done in Android.

I do most of my work in java (https://github.com/mP1)... so i am familiar with it. Java is a high level language, and the native optimisations are done by the JVM vendor which basically boils down to Oracle today.

Some people might write some native code that is faster, but that is hardly the norm.

There are many classes of programs that dont work particularly well if written in java, such as video editing or graphics because you know the rest.

They do, this idea is as old as UNCOL in 1958.

Regarding OSes still being sold today that use this idea, IBM i with Timi, Unisys ClearCase (started as Burroughs B5000 in 1961), Android, Java and .NET on embedded devices.

Then we have the ones from past times, Xerox PARC workstations with programmable microcode, Modula-2 M-Code on Lilith, Oberon slim binaries, Inferno with Limbo, Pascal UCSD P-Code, Andrew Compiler Toolkit...

Ah, and the WebAssembly folks pretending they are the very first with this idea.

How many users does UNCOL or Xerox PARC have today ?

Not many.

The main o/s we all use today such as Linux/MAC/Windows dont and Im asking why not given the advantages such a binary would give.

«Why dont O/S support executables with something like LLVM binaries and generate the native code at load time ?»

I've wondered this too. I can think of two systems "IBM i" (formerly OS/400) [1] and Oberon "Slim Binaries" [2] off the top of my head. I suspect that the answer to your question is some mix of path dependence and engineering trade-offs.

[1] https://en.wikipedia.org/wiki/IBM_i [2] https://dl.acm.org/doi/pdf/10.1145/265563.265576

For example, if the system has unix-style paged virtual memory (which Oberon did not), it's probably convenient to be able to directly map pages of native instructions into memory without needing to translate or massage them first.

In the case of "IBM i", which I've only ever read about, it sounds like it moves complexity from e.g. the compiler into the loader and so closer to the Kernel of the operating system. If I wanted to better understand the net cost/benefit analysis of this design I'd look for more detail on work done to port to PowerPC.

It does exist in LLVM and is called Bitcode, a binary format for the LLVM IR - https://llvm.org/docs/BitCodeFormat.html

Apple used to require apps submitted to its iOS App Store to be in the Bitcode format, and they would «recompile» the Bitcode into the exact user's iPhone CPU architecture at the download time – pretty much what OS/400 does. For reasons unknown, they have discontinued Bitcode.

The reasons are quite clear.

Contrary to other bytecode formats, LLVM bitcode is not stable, even across minor releases.

So anyone using it as bytecode format, like Apple, has to keep their own branch, and eventually it becomes too much work.

Microsoft did the same for DirectX DXIL, as did Khronos with the original SPIR definition, thus SPIR-V came to be as replacement, and recently Microsoft also decided to replace DXIL with SPIR-V.

Functionally, Bitcode delivers – a .bc file can be compiled into any architecture LLVM supports. I have tested a few supported architecture, and it worked like a charm.

Stability of the Bitcode format across releases is orthogonal to the functionality it provides. Given that OS/400's TIMI has been a long-running success, it is possible to put extra effort into stabilising the Bitcode format as well. Benefits would be numerous and significant, ranging from CI/CD to apps taking advantage of new or enhanced ISA extensions.

Yeah but that is the thing, for those that care about stability there are better options already.

Starting by the hyped WebAssembly, which I reckonignise it is useful, only not as breakthrough as it gets advertised given how many bytecode formats have existed since 1958.

Would that support self modifying code?

Self modifying code is frowned upon on modern platforms, due to its security implications.

Self modifying code is not allowed on some o/s because pages with code are marked as non writable, because bad things can happen when code is writable, eg buffer overflows.

Reply on news.ycombinator.com