He’s talking about static compiling of bytecodes, not even AOT. The delay will be at install time, not load time.
This is already something that iOS seems to do. The iOS clang/LLVM outputs bitcode (as opposed to the other IR that LLVM also uses), and that is compiled on the fly by the Apple servers to code specific to the target. So you can have a pretty generic exe, and make one for various versions an ARM processor. This kind of magic would be interesting. But the expense is decently debugging it. Most average developers these days don’t know one end of a stack trace and dump file from the other. I guess, you just add a level of complexity that I don’t see a point to for regular targets. I don’t want to debug a VM, nor do I want to lose symbolic debugging.
An IL for this purpose sounds like it could be useful. But it should be part of the build process - end users should never be exposed to it.
I’d also say using something like LLVM would be a great idea, because the purpose would be to generate a native exe of some type. I also like the idea of taking an app from one architecture and having it run on others. But ait also sounds like it should work along side native compilation, and should effectively be another target for the compiler. The exe code would then be retargeted once, and that would form the exe for the specific platform. I could buy in to that. Imagine developing your app in IA32, then uploading a universal package and the package server delivers a platform specific version seamlessly. That would be impressive.
1 Like
VM, loading executable sections, relocation… all sounds dynamic and dynamic loading to me. But if the bytecode can really be statically recompiled then installation time would be perfect. I’d expect a whole bunch of caveats/challenges to do with indirect address target resolution/dynamic dispatch/self modifying code etc. I don’t know if the bytecode already resolves that (I don’t know anything about WASM semantics).
Don’t worry, as a Haiku developer, I have other priorities and I will not even take part into this discussion as that would just be wasting my time!
Back to debugging my real world problems now.
7 Likes
»On a sunday morning, Haiku is the first system I boot.« is a wonderful claim.
1 Like
Right now I’m just running Haiku as a test system… but I’d say maybe, in the future, if it keeps developing in the direction it’s currently going, I’d probably use it just to avoid the kind of impatient outbursts I have when using other OSes. Explanation: my main OS is currently Windows 7 (I know, “eww”), and the biggest issue I have with that is this: it just takes too long to do things (booting up, launching apps, etc.). Haiku is much, much faster at completing such tasks on the same machine. Thus, if it’s as fast when R1 is released as it is now, it’d save me, and other similarly short-tempered folks, a few headaches. I know, it’s a personality flaw on my part - but I still consider it a valid point. 
2 Likes