Assembler, but not at all

[parisse]

Well, the MicroPython implementation is not a 2.5 year work, because nobody really worked on it (at least publicly) since the initial port by Cyrille, with a few modules that I wrote myself for other calculators. MicroPython problems happens in the UI, not in the interpreter itself which is well debugged.
I don't really know how much work it would be for wasm3. But if I had to make a choice based on how hard it would be compared to what you propose, I would certainly say it's easier. One reason is that the code for wasm3 already exists, is mature, and runs on a variety of OS/CPU, meaning you could debug easily on the emulator.

[Jean-Baptiste Boric]

(10-13-2023 01:16 PM)komame Wrote:  Wasm3 is a great idea, and I would really love for it to be possible, but only under the condition that it can genuinely be done with relatively little effort.

Python support in calculators is a matter of programming environment. A decent implementation requires an interpreter (off-the-shelf MicroPython usually), an editor, an interactive console, script management, documentation (including on-calc), completions and toolboxes, platform-specific modules... It's much more than just running Python scripts ; a whole bespoke, on-calc programming environment is necessary.

Wasm support in calculators is a matter of runtime environment. All that is required is a runtime (which is off-the-shelf) and some platform bindings, alongside some offline documentation. There's no need to implement a wasm development environment on-calc, which would be the bulk of the work for Python support.

Assuming a pure interpreter is a requirement, wasm3 is probably one of the best options here. Performance should be decent enough for games if bindings expose things like 2D and 3D drawing operations that already exist on the HP Prime ; pure number crunching would be another story, especially since wasm3 doesn't appear to support the fixed-width SIMD core proposal. Another option could be a runtime with JIT and/or AOT compilation capabilities, which could be swapped in at a later time if necessary.

It's a bit of a shame that after most calculators manufacturers coalesced around Python (but still managed to fumble modules with proprietary platform bindings...) there was no similar push for WebAssembly. A vendor-neutral, cross-platform runtime for community programs and apps would be revolutionary and help break down barriers between calculator communities.

[komame]

(10-13-2023 05:47 PM)Jean-Baptiste Boric Wrote:  Wasm support in calculators is a matter of runtime environment. All that is required is a runtime (which is off-the-shelf) and some platform bindings, alongside some offline documentation. There's no need to implement a wasm development environment on-calc, which would be the bulk of the work for Python support.

Yes, I think wasm3 is a good direction. However, wasm and the solution I was talking about are solutions for two different types of users. From the wasm perspective, we get high code portability with relatively high performance, but it forces us to use a PC to create anything. On the other hand, what I proposed was meant to be an addition to MicroPython or PPL to support performance-critical code sections at the CPU level (and based on my experience with the x86 assembler compiler I once wrote, I still believe that creating a basic ARM compiler [within the scope I described in the 1st post] in C++ can be achieved in less than two weeks).

Alternatively, the ideal solution for me would be, in addition to running entire wasm applications, to also have the ability to make insertions in PPL or Python code with calls to compiled wasm procedures. This would allow most of the code to be created and modified directly on the HP Prime (many people still do this), and only some parts to be created on the PC. In such a case, wasm would truly become a sufficient solution.

[Claudio L.]

(10-12-2023 03:31 AM)komame Wrote:  The same program implemented in PPL would look like this:

Code:

EXPORT LOOPS()
BEGIN
  LOCAL i;
  REPEAT
    i:=i+1;
  UNTIL 0;
END;

and after 60 seconds, the result is 2,950,000 (firmware 14730, tested just after soft reset). So, for one loop cycle, PPL requires 10738 CPU cycles.

...
EDIT: I forgot that I still have the G1, which primarily differs from the G2 in its CPU architecture (ARMv5 vs ARMv7) and the actual processor clock speed is just a little over 20% difference. In this test, the G1 [400MHz] scores as follows: 845,000 iterations / 28402 CPU cycles per one loop iteration (so it is worse than RPL on HP49G), which unfortunately confirms that under such conditions, RPL would probably take the lead (but this doesn't reflect well on RPL, it just reflects poorly on PPL).
...

NewRPL running this test on the Prime G1 did 1,878,000 in 60 seconds.

[parisse]

If I had to implement wasm support, then my plan would be to support it inside the CAS eval command. You would call something like eval("wasm","code or filename",optionnal args).

[Jean-Baptiste Boric]

(10-14-2023 04:12 PM)komame Wrote:  Alternatively, the ideal solution for me would be, in addition to running entire wasm applications, to also have the ability to make insertions in PPL or Python code with calls to compiled wasm procedures. This would allow most of the code to be created and modified directly on the HP Prime (many people still do this), and only some parts to be created on the PC. In such a case, wasm would truly become a sufficient solution.

Theoretically there's a middle-ground possible: to use the wasm runtime to run a toolchain directly on the calculator, with a compiler hosted on wasm32-wasi and targeting wasm32-wasi. Assuming the HP Prime implements the WASI specification (or at least the subset needed for this) and that the toolchain fits within the memory constraints of the calculator, it would be entirely self-hosted on the calculator.

[Claudio L.]

I don't know if it's of any interest, but newRPL does provide a quasi-assembler syntax in case RPL is not your thing:

https://newrpl.wiki.hpgcc3.org/doku.php?...apter5:asm

It's still bytecode, same as compiled RPL but is much more compact with one instruction reading, indexing, doing math, and storing the result.
Unfortunately, newRPL does not run on Prime G2, only Prime G1.

[komame]

(10-18-2023 02:46 AM)Claudio L. Wrote:  I don't know if it's of any interest, but newRPL does provide a quasi-assembler syntax in case RPL is not your thing:

https://newrpl.wiki.hpgcc3.org/doku.php?...apter5:asm

It's still bytecode, same as compiled RPL but is much more compact with one instruction reading, indexing, doing math, and storing the result.
Unfortunately, newRPL does not run on Prime G2, only Prime G1.

I just installed newRPL on the G1 and I'm trying to test it, but I couldn't find a keyboard description and I'm struggling.

[Claudio L.]

(10-18-2023 05:41 PM)komame Wrote:  

(10-18-2023 02:46 AM)Claudio L. Wrote:  I don't know if it's of any interest, but newRPL does provide a quasi-assembler syntax in case RPL is not your thing:

https://newrpl.wiki.hpgcc3.org/doku.php?...apter5:asm

It's still bytecode, same as compiled RPL but is much more compact with one instruction reading, indexing, doing math, and storing the result.
Unfortunately, newRPL does not run on Prime G2, only Prime G1.

I just installed newRPL on the G1 and I'm trying to test it, but I couldn't find a keyboard description and I'm struggling.

The keyboard tried to follow what's painted but with a 50g vibe: There's 3 shifts, On is now a shift, the blue shift key is the other one and Alpha is Alpha like the 50g.
On moved to the ESC key. From there most of the things on the wiki which was written for the 50g will apply. The 6 menu keys are around the cursors. The second menu doesn't have dedicated 6 keys. If you built from source you'll have touch support but if you didn't then the MNU key on the right will swap which menu is "active". The 6 keys will do the function of the active menu only.
For example to turn it off you'd normally do Shift+On, here you'll do On (which is a shift) + ESC (which is On). It will take some getting used to but is not that bad in the end, especially if you are familiar with the 50g ways.

[komame]

Here is a truly great example of how fast HP Prime can be if access to machine code were unlocked (most likely wasm would also be sufficient). Considering the smoothness of the animations, I think HP Prime could do much more than what is shown here.

https://www.youtube.com/watch?v=Nq497U3KPs0

Best wishes,
Piotr

[dlidstrom]

(11-01-2023 07:06 AM)komame Wrote:  Here is a truly great example of how fast HP Prime can be if access to machine code were unlocked (most likely wasm would also be sufficient). Considering the smoothness of the animations, I think HP Prime could do much more than what is shown here.

https://www.youtube.com/watch?v=Nq497U3KPs0

Best wishes,
Piotr

Cool video! How was it done? Looks like a small Linux with Doom installed?

[komame]

(11-12-2023 07:57 PM)dlidstrom Wrote:  Cool video! How was it done? Looks like a small Linux with Doom installed?

Yes, it's possible, but it's a bit risky, so it's not for everyone.
The procedure is described here:
https://github.com/zephray/prinux

Piotr

[komame]

Full MicroPython includes such a feature: inline-assembler, accessible using the decorator @micropython.asm_thumb. Since this already exists in MicroPython, it would probably be possible to make it available on the HP Prime as well.
This would provide incredible performance (over time, libraries could be developed that were equally or even more efficient than libraries written in C) and additionally, there would be the possibility of modifying the program directly on the HP Prime.

https://docs.micropython.org/en/latest/r..._tips.html

Of course, to address concerns about misuse of this mechanism, this decorator should be unavailable in exam mode.