Update from PMDG

[bb010g 3]

6 hours ago, eaim said:

So are there any limitations in using webassembly, I seem to remember some devs claiming that it's limits usage to a single core?

Sorry if it's stupid question as programming wise I'm a bit out of date, I done my A level computer science 35+ years ago.

inNative has thread support: innative-sdk/innative#57 . innative-sdk/spec documents the current WebAssembly standard implemented by inNative, including any proposals like threading. As for compiling modules utilizing the threading proposal's instructions, I'm not sure, but you should be able to ask the MSFS devs (or, worst case, the inNative devs in their Discord) about how to compile with threading from at least Clang. https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html is an older blog post discussing compiling Rust to WASM with threads support.

This is a non-obvious feature, so thanks for your question!

[Scottoest 1,561]

On 11/30/2020 at 4:14 AM, bb010g said:

Hi, programming nerd here to set the record straight on some MSFS 2020 things.

Flight Sim 2020 uses inNative (source code) to compile WebAssembly (WASM) into native machine code via LLVM. (Check the credits and you'll see inNative listed.) Restated for programmers, inNative is a WASM LLVM frontend, compiling WASM into LLVM IR and then letting LLVM do its normal thing. LLVM is the same backend that Clang, one of the major C++ compilers (alongside GCC & MSVC), uses. WebAssembly code can be compiled to native code completely before execution, and, depending on how you invoke inNative, any native API can be used from WASM modules. With the right configuration, you can compile arbitrary normal Windows C++ programs to WebAssembly and then to native code via inNative and have them execute virtually identically (modulo optimizations). (MSFS 2020 does not allow for this usage, by design.)

Microsoft Flight Simulator 2020 is not interpreting WebAssembly like your browser would, but instead utilizing it as a portable, well-designed, low-level, sandboxed language. Instead, WASM modules can provide native performance to the same code on essentially any platform MSFS wants to run on, without extra development work.

WebAssembly by itself offers no platform-specific APIs (they're considered unnecessary bloat), but it does offer the ability to import functions from the "host". inNative allows arbitrary C ABI (application binary interface) functions to be exposed to WebAssembly modules, which may import them if they please, like how a linker traditionally functions, linking libraries (like SOs or DLLs) together.

MSFS is not constrained in what it exposes by its use of WebAssembly, and as such any missing SimConnect functionality is most likely due to normal difficulties of implemention & integration with the sim.

File system APIs have also been brought up a decent amount here in what I've read, and exposing those is also in MSFS's court. I believe MSFS implements or is implementing WASI, the WebAssembly System Interface, a standard for file-system APIs in WASM? Note that whatever is chosen, it will basically perform as fast as C++ code compiled directly from source to LLVM IR & then native through Clang, given the same interface. The choices of file-system interfaces exposed may effect performance, but this is something you can reasonably bring up to Asobo as an extension to their existing host function set that would really improve your add-on. Any function added there would be accessible with full native performance from your WASM modules.

inNative not only can perform AoT (ahead-of-time) compilation, but also JIT (just-in-time) compilation via LLVM's JIT API. For the JIT, a WASM module is compiled to LLVM IR by inNative and then to native code by LLVM that can then be executed right on the spot, instead of the native code being output to a file or other longer-living storage. This isn't used much AFAIK, and I don't think may be used on the Xbox at all(?), but it can help make development smoother (less time waiting between testing iterations). (The fact that inNative is an AoT compiler is a large part of why it was chosen, AFAIK. Official add-ons can use the same SDK as community add-ons and be compiled before deployment for the Xbox, so that no code has to be compiled (security hazard) or interpreted (performance hazard) on the Xbox.)

Also, on the topic of WebAssembly & graphics APIs (e.g. DirectX), they're really separate issues. WebAssembly doesn't target shader or GPU compute programming in the same way C++ doesn't normally target those. You'll instead have APIs for talking to the operating system & graphics drivers (which can be exposed to WASM no problem & without damaging performance), and then separate languages like HLSL (OpenGL, DirectX) or SPIR-V (Vulkan) that some of those APIs deal with for encoding high-performance GPU programs. MSFS is free to choose graphics backends independent of WebAssembly, and whatever they decide to expose via WASM host functions will cost no performance (compared to the same functions in directly native code).

Yeah, well, that's just, like, your opinion man.

[Carts85 1,203]

18 minutes ago, Scottoest said:

Yeah, well, that's just, like, your opinion man.

Haha made me laugh this, well played