Former WebAssembly Plans
Anyone who has known me since I’ve started posting to this forum knows that my ideal scenario for WebAssembly is that cross-platform bytecode files could be made according to the WASI standard for architecture-neutral apps. Recent events may turn my ideal scenario totally on its head and my plans for Haiku with it.
Using an NPU to Change That
The vaguely-named neural-processing-unit (NPU) is a recent addition to x86-64 models and some Qualcomm Snapdragons on ARM64 as well. While all the hype surrounding it seems to be directed toward A.I. and all the hullabaloo associated with it but parts of an NPU may be useful for other, more common and useful tasks.
Of particular note is the fact that linear algebra is coprocessed by NPUs such as the matrix functionality used by the PBQB register allocator in LLVM. If that particular function is made demonstrably faster, using WebAssembly bytecode could be made much more painless, along with any other LLVM-based production compilation. So far LLVM-based static compilers are not limited to WebAssembly but also exist for JavaScript as well.
The Downsides
If WebAssembly continues to be adopted for its intended purpose as a means of making web-apps faster and more efficient, the ideal of using clever tricks at the OS level to improve usability of the system could be fading fast. So far, most WebAssembly exercises have been web-based and the WASI standards are basically an afterthought. If this trend continues, the milestones that would be reachable about improving an OS will be rendered irrelevant by the browser apps’ improvements.
I’ve long viewed web-development as redundant with system development but always hoped that system programmers’ efficient code would win in the end. This is no longer looking like the case because with a static installation of production-grade web-apps, the roles of system programming and web-development could become so utterly interchangeable that they’ll all be competing for the same clients. Programming languages like Dart Native that used to support all types of mainstream OS apps as well as web-apps will become unnecessarily expensive to maintain.
The Fallout
Even the smallest and most clever operating systems will become as obsolete as any other operating systems as browser-based systems like ChromeOS will become the simplicity of the mainstream while traditional operating systems will fade out. Their features will be ignored and eliminated. Basic browser infrastructure like RSS feeds will be enough to supplement or even replace package management.
The Light at the End of the Tunnel?
Once the browsers and operating system functions are integrated so fully that browser essentially run on the bare metal and the bare metal becomes architecture neutral, mainstream OS development will likely cease as well. My hope to make drivers a macro-expansion of a hardware register map that is independent of the headers that wrap it using generics or similar functions could be manifested.
The end of Native apps could ensue though. The light at the end of the tunnel may be the train.