Public Beta Availiable - Win/Firmware

[Jean-Baptiste Boric]

(04-17-2021 06:36 AM)parisse Wrote:  Casio has support for native code (addin) on their calculators. I don't think it's unrealistic to hope the same on HP. The HP Prime has a much more capable hardware (no 2M upper limit for example), that could attract more developers and make the Prime more attractive for all users.

Casio is willing to support native code, which is a good thing. HP hasn't shown any sign that they would be willing to reconsider their position on the matter ever since the original HP Prime was introduced back in 2013. Given that constraint, I'm searching for a solution that has a non-zero probability of happening.

(04-17-2021 06:36 AM)parisse Wrote:  It's more than just some extra bits. My main concern is that I can not publish myself a fixed firmware when someone detects a bug in the CAS, or if I want to bring improvements. For example, I'm currently improving symbolic integration code in giac, I will probably publish a revised nspire version in a couple of weeks but I don't know when it will be available on the Prime.

Although this was somewhat in jest, I failed to consider that this would be a solution for providing updated giac builds faster than the official channel. My bad.

(04-17-2021 06:36 AM)parisse Wrote:  wasm is already supported by giac with emscripten (e.g. in Geogebra, Xcas for Firefox, Tableaunoirxcas). But it's not as simple as you say to port libraries. It's easier to port libraries with a cross ARM toolchain. And of course you will have a performance penalty. With a good wasm implementation, mean performance loss is a factor of 3 for giac (e.g. inside Firefox), but it can be much more for bigint computations (7 or 10 times for Groebner basis computations for example). Wasm3 would probably be at least 10 times slower (mean) and up to 50 times slower for large computations and that's significant for CAS.
And it's not clear that adding wasm support would require less work than adding native code support...

To summarize my points on why I think WebAssembly is a good candidate here:

• Integrating an off-the-shelf WebAssembly runtime library should be as hard as integrating the MicroPython runtime. WebAssembly doesn't require a shell, a script editor or complex UI.
• Native code is not portable between the different platforms supported by the HP Prime ecosystem (physical calculator, smartphone/tablets apps, desktop simulators...). Separate add-ins builds are required for every supported platform. Every supported platform requires platform-specific glue. Side-loading native code is not allowed on iOS by policy. For an ecosystem that offers a consistent feature set across all platforms, native code would feel like an afterthought at best.
• WebAssembly is sandboxed by design, which is important not only for security but also for stability. Native code requires complex technical solutions for that (at the minimum privilege separation with a separate address space).
• It's an open industry standard supported by the LLVM toolchain. Most program and libraries can be ported to it, which would open up the HP Prime ecosystem by enabling ports of existing software, including KhiCAS.
  

Indeed, it's not as fast as native code, especially if an interpreter-only runtime is integrated. However, I believe that for most usages it would be fast enough on the physical calculator. If people really want better performance in order to run Quake on their calculators at an acceptable framerate, HP could change the WebAssembly runtime for one with JIT or AOT compilation support in a later release without breaking compatibility. It's not a technological dead-end.

Yes, ideally HP would support native code and we wouldn't even be having this discussion in the first place. If you can convince them to change their mind on that topic then good, in the meantime I'm advocating for a technical solution that gets us most of the benefits for native code support without actually having native code support, so that it has a non-zero probability of happening.