mirror of
https://gitlab.com/c3d/db48x.git
synced 2024-09-29 05:36:58 +02:00
b0cf9d9537
Relatively significant documentation update: 1. Move Story.txt to 2-Quickstart.md. This will later be fleshed out to be a full Quickstart guide. For now, it's simply a description of what to talk about in a movie There was a bit of reordering to improve the flow as well. 2. Add links to issues and PRs to invite people to submit them 3. Move the Types section in file 3-Types.md Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
102 lines
5.4 KiB
Markdown
Executable file
102 lines
5.4 KiB
Markdown
Executable file
# Introduction to RPL
|
||
|
||
The original RPL (*Reverse Polish Lisp*) programming language was designed and
|
||
implemented by Hewlett Packard for their calculators from the mid-1980s until
|
||
2015 (the year the HP50g was discontinued). It is based on older calculators
|
||
that used RPN (*Reverse Polish Notation*). Whereas RPN had a limited stack size of
|
||
4, RPL has a stack size only limited by memory and also incorporates
|
||
programmatic concepts from the Lisp programming language.
|
||
|
||
The first implementation of RPL accessible by the user was on the HP28C, circa
|
||
1987, which had an HP Saturn processor. More recent implementations (e.g., HP49,
|
||
HP50g) run through a Saturn emulation layer on an ARM based processor. These
|
||
ARM-based HP calculators would be good targets for a long-term port of DB48X.
|
||
|
||
DB48X is a fresh implementation of RPL on ARM, initially targetting the
|
||
SwissMicros DM42 calculator. This has [implications on the design](#design-overview)
|
||
of this particular implementation of RPL.
|
||
|
||
## The RPL stack
|
||
|
||
The RPL stack can grow arbitrarily in size.
|
||
|
||
By convention, and following RPN usage, this document gives the names `X`, `Y`,
|
||
`Z` and `T` to the first four levels of the stack. This is used to describe the
|
||
operations on the stack with synthetic stack diagrams showing the state of the
|
||
stack before and after the operation.
|
||
|
||
For example, the addition of two objects in levels 1 and 2 with the result
|
||
deposited in stack level 1 can be described in synthetic form using the
|
||
following stack diagram:
|
||
|
||
`Y` `X` ▶ `Y+X`
|
||
|
||
The duplication operation `Duplicate` (`DUP`) can be described in synthetic form
|
||
using the following synthetic stack diagram:
|
||
|
||
`X` ▶ `X` `X`
|
||
|
||
|
||
## Algebraic mode
|
||
|
||
Unlike earlier RPN calculators from Hewlett-Packard, RPL calculators from HP
|
||
includes complete support for algebraic objects written using the standard
|
||
precedence rules in mathematics. This gives you the best of both worlds,
|
||
i.e. the keyboard efficiency of RPN, requiring less keystrokes for a given
|
||
operation, as well as the mathematical readability of the algebraic
|
||
notation. Better yet, it is possible and easy to build an algebraic expression
|
||
from RPN keystrokes. These nice properties are also true for DB48X.
|
||
|
||
In RPL, algebraic expressions are placed between ticks. For
|
||
example, `'2+3×5'` will evaluate as `17`: the multiplication `3×5`, giving `15`,
|
||
is performed before the addition `2+15`, which gives `17`. An algebraic
|
||
expression can also be symbolic and contain unevaluated variables. For example,
|
||
`2+x` is a valid algebraic operation. If, having this expression on the stack,
|
||
you type `3` and then hit the `×` key, you will end up with `(2+x)×3`, showing
|
||
how the algebraic expression was built from RPN keystrokes.
|
||
|
||
Algebraic expressions are not evaluated automatically. The _R/S_ key (bound to
|
||
the [Evaluate](#evaluate) function) will compute their value as needed. On the
|
||
DB48X keyboard overlay, this key is also marked as `=` for that reason.
|
||
|
||
## Rich data types
|
||
|
||
Since introducing the first scientific pocket calculator, the HP-35, in 1972,
|
||
and with it the reverse polish notation (RPN), Hewlett-Packard perfected its
|
||
line-up for decades. This led to such powerhouses pocket computers such as as
|
||
the HP-41C series, or tiny wonders of pocket efficiency such as the HP-15C. Many
|
||
of these calculators, including the models we just cited, were capable of
|
||
advanced mathematics, including dealing with complex numbers, matrix operations,
|
||
root finding or numeric integration.
|
||
|
||
Then in 1986, everything changed with the HP-28C, which introduced a new user
|
||
interface called RPL. While the most evidently visible change was an unlimited
|
||
stack, what instantly made it both more powerful and easier to use than all its
|
||
RPN predecessors was the introduction of [data types](#types). Every value
|
||
on the stack, instead of having to be a number, could be a text, a name or an
|
||
equation. This made operations completely uniform irrespective of the data being
|
||
operated on. The same `+` operation that adds numbers can also add complex
|
||
numbers, vectors, matrices, or concatenate text. The exact same logic applies in
|
||
all case. This solved a decade-long struggle to extend the capabilities of
|
||
pocket calculators.
|
||
|
||
For example, whereas the HP-41C had some support for text, with an "Alpha" mode
|
||
and an alpha register, text operations were following their own logic, with for
|
||
example `ARCL` and `ASTO` dealing with at most 6 characters at a time, because
|
||
they were artificially fitted in a register designed to hold a numerical value.
|
||
Dealing with complex numbers on the HP-41C was
|
||
[similarly clunky](https://coertvonk.com/sw/hp41/complex-arithmetic-xmem-4426).
|
||
Even the HP-15C, which had built-in support for complex numbers, remained a bit
|
||
awkward to use in "complex mode" because its display could only show one half of
|
||
a complex number, e.g. the real or imaginary part. Similarly, matrix or
|
||
statistic operations had non-obvious interactions with numbered data registers.
|
||
|
||
All this was solved with RPL, because now a complex number, a matrix or a text
|
||
would occupy a single entry on the stack. So whereas adding two integers would
|
||
require a sequence like `1 ENTER 2 +` like in RPN, a very similar sequence would
|
||
add two texts: `"ABC" ENTER "DEF" +`, and the exact same logic would also add
|
||
two vectors in `[1 2 3] ENTER [4 5 6] +`.
|
||
|
||
DB48X adopts this extremely powerful idea, with a focus on making it as
|
||
efficient as possible for interactive calculations as well as for custom
|
||
programmed solution.
|