Reviving Reverse Polish Lisp (RPL) - FOSDEM 2023 talk

[@JohnUsp]

Awesome, congrats and thank you so much for your work.

[@perfectman3077]

Amazing achievement

[@frankwc0o]

RPL is so cool. Grew up in the late 80's and the 48sx, it's probably the best calculator HP ever made in the 80's. Do you have a video on how to load this on a DM42? Also, are there any faceplates for this?

[@christophe3d]

Hello, I have a whole playlist on the topic: kzbin.info/www/bejne/jYaYdZpnorWeopo. Installation instructions specifically are here: kzbin.info/www/bejne/qIe6qmeEZdF1has. As for the keyboard overlays, please check the link at the bottom of 48calc.org/documentation. The thread on HP Museum is here: www.hpmuseum.org/forum/thread-20113.html (to save you a click).

[@christophe3d]

You are correct that the 48SX was probably the best calculator HP ever made (not just in the 80s). After that all the ARM-based calculators demoted RPL / RPN to an afterthought, which is plainly visible with the annoyingly small and misplaced ENTER key. The UI was much easier to discover for newbies, but worse for seasoned users (it's a bit like Notepad vs. Emacs). The Prime, despite fantastic hardware, went even further in that direction, and targets students so exclusively that the unadjustable font size is unusable for anyone entering old age.

[@frankwc0o]

@@christophe3d Thanks for the information. I can’t wait to use it on my DM42. I hope it gives me some memories of my 48sx, which I still have, but like many of these HP calculators, the bezel issues is present.

[@KipIngram]

This is an OUTSTANDING project. As you said, there's work to be done, but this feels like the right approach. Is there any way we can help with the work?

[@christophe3d]

Go to the github page, test it, improve the documentation, file issues.

[@0LoneTech]

The repository is c3d/DB48X-on-DM42 (looking at it now)

[@lmamakos]

This is amazing work! I think I might replace C47 on my DM42 with this, which would complement newRPL on an HP 50g and HP 48gs calculators that I have! It is too bad that newRPL can't fit on the platform; bringing some of the UI changes (like how you handle the menu keys and command completion) to newRPL on a new platform would have been nice. Thank you for the video presentation and, of course, all the work on the code.

[@christophe3d]

Thanks!

[@max5250]

Christophe, this was very insightful video, with a lot of information about your project, SwissMicros hardware and hp48 in general. I was never attracted to dm42 since I had hp28s and, I am accustomed to RPL and unlimited stack (and not FOCAL and limited PRN stack), but now that you are developing DM48X, I am considering purchase of DM42 for repurposing into DB48X. Question: Is there possibility to download DB48X simulator executable for Windows?

[@christophe3d]

DB48X, not DM48X (DB is for "Dave and Bill", that's why it matters ;-) The simulator is written using Qt, so in theory it should be possible to build it for Windows. I know that I built it successfully for Linux recently. That being said, I generally don't develop on Windows, and I won't spend time on this. I would welcome a third party build, though. Any volunteers?

[@max5250]

@@christophe3d Ooooops… sorry for my mistake(s), I know all about naming convention you used (and I fully support it).

[@fabien2430]

ha, si seulement on pouvait avoir les deux touches shift comme sur la série des hp48 sur cette DM42. c'est une DM48 qu'ils aurait du faire :)

[@christophe3d]

Talk to SwissMicros for a DM48, but before you do, please be aware that they were quite dismissive of my approach with DB48X. They are in the business of making clones, that work almost exactly like the original. They were not particularly appreciative of the effort I put into running well on a DM42. Frankly, the key placement optimizations now are such that it's much faster to use DB48X on a DM42 than to use RPL on an HP48. I know, I compare on a quasi-daily basis ;-)

[@christophe3d]

Zut, j'ai répondu en anglais. La force de l'habitude sur KZbin. Je n'avais pas de touche que j'étais prêt à sacrifier pour gagner une touche bleue, et en pratique, le double shift est une habitude qu'on prend très vite. Aujourd'hui, je vais beaucoup plus vite en général sur DB48X sur une DM42 que sur une vraie HP48 (et a fortiori sur une HP50 où ils ont mis "ENTER" à la place du +), même si le clavier reste meilleur sur la HP. C'est une question d'optimisation du placement des touches.

[@christophe3d]

Pour compléter ma réponse précédente… Lorsque j'ai discuté avec SwissMicros la possibilité qu'ils produisent une DM48 basée sur DB48X (ce qui était, en terme d'efforts pour eux, un nouveau overlay pour le clavier et un nouveau lien de firmware sur leur site web, c'est à dire à peu près zéro), ils m'ont répondu que j'aurais du demander à avoir une rangée de touches en plus, et que de toutes façon ce que j'avais fait n'allait pas parce que ça n'était pas parfaitement compatible avec la HP48. Un peu douche froide, pour être franc. Du coup, je suppose que s'ils essayaient de faire une DM48, ce serait avec la disposition de touches de la HP48, et, j'imagine, en émulant la ROM d'origine, parce que sinon tout le code tiers, les librairies en assembleur, le metakernel, les jeux ne pourraient pas marcher. En gros, X48 ou iHP48 en format physique. Je leur souhaite bonne chance, parce que les ROMs HP ne sont normalement pas exploitables pour utilisation commerciale, l'affichage à l'écran poserait un vrai problème compte tenu de la résolution de la HP48 par rapport aux écrans actuellement utilisés dans leurs produits, et même une machine avec un CPU ARM nettement plus rapide comme la HP50 ramait pas mal à faire de l'émulation. Bref, ça ferait à mon avis un produit assez mauvais. Mais c'est juste mon opinion, rien d'autre. Ils font ce qu'ils veulent. Quoi qu'il en soit, cette approche là ne m'intéresse pas du tout personnellement, et ce n'est pas une machine que j'achèterais. Ce que je veux, c'est une calculatrice moderne, pas de faire du retro-computing juste pour l'effet nostalgie. Je développe ce projet parce que j'en ai l'usage, et que j'atteins très souvent les limites de la vraie HP48, de la HP50, de la HP Prime ou de machine plus modernes genre NumWorks. J'essaie de faire la calculatrice dont j'ai toujours rêvé, pas une copie d'un truc existant. L'esprit de la HP48, c'était de repousser les limites de l'époque, pas de copier servilement ce qui avait été fait avant. C'est cet esprit d'innovation et d'excellence de Hewlett-Packard dans les années 1990 que j'essaie de faire revivre, pas un code vieux de trente ans. Il y a un certain coté nostalgique bien sûr, ne serait-ce que parce que j'ai travaillé 16 ans chez HP, et que j'ai bien connu l'époque du HP Way, avant Mark Hurd et Carly Fiorina, époque bénie où les ingénieur s'éclataient à faire des produits aussi bons que possible, assez avancés pour rester inégalés trente ans plus tard. Cet esprit innovant et centré sur les besoins pointus d'utilisateurs "avancés", qui primait à l'époque chez HP, c'est ça que je veux intégrer dans DB48X, c'est ça que j'appelle "l'esprit de la HP48". Faire tourner une vulgaire copie du code binaire produit par HP à l'époque serait pour moi une insulte envers les types qui ont écrit ces ROMs, dont plusieurs que je connais personnellement. Faire quelque chose de moderne inspiré par leur travail, d'un autre coté, c'est leur rendre un vrai hommage, et c'est pour ça qu'ils sont dans la page "Acknowledgements" du projet. Naïvement, je pensais que DB48X, en offrant à SwissMicros la possibilité d'explorer un marché au delà des collectionneurs nostalgiques, pouvait les intéresser, voir générer un certain enthousiasme. Clairement, ce n'est pas le cas. Ils ont une niche, l'émulation de machines RPN du siècle dernier, et pour autant que je comprenne, ils souhaitent s'y tenir. En attendant, ils m'ont fourni une plateforme hardware plutôt décente (*)(**), et j'en profite. (*) Quand on fait tourner DB48X en simulation sur du matériel plus moderne, on se rend quand même compte des limites des ARM "low cost" et "low power". (**) Sauf comme vous le fîtes remarquer, que ça manque cruellement de touches…

[@KipIngram]

Impressive. But... is RPL really that bloated? I work a lot with Forth, and for Forth 96k is a gorgeous plenty. I'm working on one now for the Cortex M4F that I think will come in around 6kB or so for a "complete" Forth OS, with mass storage management, a block editor etc. A fully functional Forth system. Now, that is NOT a scientific computing environment, but I'll only have used about 6% of my RAM. Maybe I'll have to see how much such functionality I could get into that platform.

[@christophe3d]

Forth is very poor relative to RPL feature-wise. When you talk about 6K, it's unclear if you are talking about RAM or Flash. If it's RAM, then you are ignoring the 10K that are required for the display memory alone, then another 10K or so for the system (if my free space goes below that, some OS operations fail, notably disk operations). So there's about 70K left out of the original 96. The RPL runtime itself consumes very little (maybe one or two kilobytes).

[@0LoneTech]

As far as I can tell, newRPL really is surprisingly clumsy. It looks like basic numeric values (REAL type) take 16 bytes before even counting the mantissa. Other oddities include tons of tables without the code to calculate them and all capital comments. As for Forth size, that meant the entire code of the base system; interpreter, compiler, standard library (including names). It wouldn't include e.g. arbitrary precision numbers or garbage collection. It's probably comparable to SysRPL. Core Forth basically sits in all the System RPL words with # in them, as well as :: (docol) and ; (semi, which forth knows as return). Flow control is very similar, extended with a Lisp cond-style case and an end word to reorder if then else end.

[@KipIngram]

@@christophe3d I was referring to the aspects of a Forth system that are normally referred to when they say a "full system" can be around 8kB - I think this one I'm planning will be smaller than that. You're right that it doesn't include display RAM or disk buffers. Or stack space, for that matter - I was referring to the size of the dictionary. But still - the number is much, much less than the 90kB or so available in a platform like the DM42. It feels like that ought to be enough to do something fairly impressive. But, I haven't tried it yet, so who knows... Another way of saying what I was referring to would be the size of the executable image you'd need in order to start the system up - I actually agree with you that's not the best metric, precisely because it does leave out some of the things you listed.

[@christophe3d]

​@@KipIngram I believe that I understand what you were referring to. And I pointed out that the reason a full Forth system is only a few kilobytes is because it typically does not include floating point support, complex numbers, matrix operations, bitmap fonts, graphic functions, plotting, symbolic operations, symbolic and numerical solvers, integration and differentiation, a built-in help system, persistent storage or an operating system. Add all this, and your Forth system will also become much larger. As a matter of fact, RPL in its original implementation started that way, to implement the original HP17B. It was a way to make code denser compared to straight assembly language. In its simplest form, interpreting RPL is three Saturn instructions: "A = DAT0; D0 = D0+5; PC=(A)", which is the equivalent of "goto *d0++". An RPL program in the HP48 form is 2.5 bytes per operation. In my implementation, it's one or two bytes (but at the cost of making the evaluation loop a tiny bit more complicated). Finally, please do not confuse RAM size and program size. On the DM42, I have about 700K worth of Flash memory I can use for the program, and about 70K of usable RAM (96K - 10K of bitmap - 10K of stack/heap - a few K of system state and variables). Experimentally, the system crashes if I leave less than 10K free. I believe that the reason is that the DM42 has a e-ink screen, so the display RAM is not directly rendered by hardware. Instead, you tell the system which display lines are dirty, and system firmware makes a snapshot of the bitmap RAM which it then sends serially over a wire to the e-ink hardware. So while the display RAM uses 10K, refreshing the e-ink display can need another 10K temporarily. As far as RPL RAM usage is concerned, when I run my tests, I typically run with 2K of RAM to stress-test the garbage collector. 2K was also what the original HP28C came with. So RPL runs fine with 2K of RAM, including in my implementation.

[@0LoneTech]

​​​​​​​​​​​@@christophe3d That inner interpreter is straight from Forth; it's known as NEXT, and the technique is known as threaded code. DB48X adds a more compact encoding of the pointers and a C++ vtable-style dispatcher (looked up via tagged type index). I'm thinking a similar encoding could probably halve the size of the pointer lists too, and the points-inside check should be factored out and made common between gc and move in runtime. Further, since the GC appears to only traverse outer objects, it may be unnecessary to LEB128-encode inner data; encodings with fixed or logarithmic size encodings could be used for inner fields, rather than linear. And cross compilation could perhaps be aided with Zig. Just bunches of vague ideas floating about. Edit: I see that inner fields (payloads) aren't necessarily LEB128. For instance, decimal128 uses a tag and sizeof(bid128). Should've realized from the ASCII data shown; text and comment have LEB128 length field, then UTF8 content, I think. Just getting oriented. Rearranging object::handler in column oriented form would improve cache locality of tight loops like the interpreter, assuming we have a data cache in the CPU. Perhaps with some selective grouping. (It's a STM32L476xx with Cortex M4F; although the CPU does not have a cache, the flash memory does.) Conclusion: cache is too small and interpreter too jumpy to affect performance significantly, but putting size and evaluate in the same double-word (8 bytes, lines are 32 bytes but only fetched in double words) could save a few cycles per operation.