Assembler, but not at all
|
10-13-2023, 04:56 PM
Post: #21
|
|||
|
|||
RE: Assembler, but not at all
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. |
|||
10-13-2023, 05:47 PM
Post: #22
|
|||
|
|||
RE: Assembler, but not at all
(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. |
|||
10-14-2023, 04:12 PM
Post: #23
|
|||
|
|||
RE: Assembler, but not at all
(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. |
|||
10-14-2023, 08:52 PM
Post: #24
|
|||
|
|||
RE: Assembler, but not at all
(10-12-2023 03:31 AM)komame Wrote: The same program implemented in PPL would look like this: NewRPL running this test on the Prime G1 did 1,878,000 in 60 seconds. |
|||
10-15-2023, 06:21 AM
Post: #25
|
|||
|
|||
RE: Assembler, but not at all
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).
|
|||
10-15-2023, 03:56 PM
Post: #26
|
|||
|
|||
RE: Assembler, but not at all
(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. |
|||
10-18-2023, 02:46 AM
Post: #27
|
|||
|
|||
RE: Assembler, but not at all
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. |
|||
10-18-2023, 05:41 PM
Post: #28
|
|||
|
|||
RE: Assembler, but not at all
(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: 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. |
|||
10-19-2023, 02:54 AM
Post: #29
|
|||
|
|||
RE: Assembler, but not at all
(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: 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. |
|||
11-01-2023, 07:06 AM
Post: #30
|
|||
|
|||
RE: Assembler, but not at all
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 |
|||
11-12-2023, 07:57 PM
Post: #31
|
|||
|
|||
RE: Assembler, but not at all
(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. Cool video! How was it done? Looks like a small Linux with Doom installed? 2xHP48GX, HP 50g, two Retrotronik ram cards, DM42 /Daniel Lidström |
|||
11-13-2023, 02:07 PM
Post: #32
|
|||
|
|||
RE: Assembler, but not at all
(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 |
|||
02-19-2024, 06:21 PM
(This post was last modified: 02-19-2024 06:23 PM by komame.)
Post: #33
|
|||
|
|||
RE: Assembler, but not at all
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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)