With the original code, the loop searching for commands to add to the
catalog skips many commands. I suspect this is another case of QSPI
hammering similar to what was observed for fonts. In any case, the
workaround appears to be to slightly deoptimize the code by selecting
a lower optimization level and adding an `else` clause in the inner
`if` statement.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
These are two catalogs that behave much like the constants catalog,
and inherit most of the code.
The equations library is intended to store standard equations.
The library is for standard objects and various useful objects or
programs.
Both can be organized by topics.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The dependency is not quite correct anyway, it's not the end result
that is dependent on the decimal headers, but the intermediate build
steps.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Refactor the code to put all date and time related functions into the
`datetime.h` and `datetime.cc` files.
Also added Julian day number calculations, which enable the
computation of the day of the week in the date format rendering, and
will make it easier to implement future commands such as `DDAYS`.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Dynamic constants menu, similar to units menu, which is populated
either from an internal table, or from `config/constants.csv`
Fixes: #497
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The hardware-accelerated floating-point support in the ARM chip is
about 2000 faster than the variable-precision decimal floating point
implementation. It makes sense to use it.
See numbers recorded in `doc/6-Performance.md` for details.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
A single 10000-digit constant takes about 4K in QSPI space.
Constants are generated in a cache and rebuilt when precision changes.
For now, store pi, which we will need to implement sin/cos/tan
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The `decimal` class represents a variable-size decimal, similar to
what can be found in newRPL.
This commit implements the base class.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
It's interesting to prove that we can build without it, but we can't
do a release without it.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
At some point, we will need to shift to variable-precision decimal.
Being able to disable all `decimal128` code will help evaluate
how much room we have for that.
With decimal128 active, sizes are:
text data bss dec hex filename
2254248 3840 2524 2260612 227e84 build/dm42/release/db48x.elf
wc -c db48x.pgm
710180 db48x.pgm
Without decimal128, sizes are:
text data bss dec hex filename
455864 2872 2412 461148 7095c build/dm42/release/db48x.elf
wc -c db48x.pgm
282236 db48x.pgm
In other words, decimal128 at the moment uses 427944 bytes out of our
716800 budget (i.e. 59.7%) and 1798384 in the total size (79.7%).
Chances that a variable decimal implementation can be made smaller
than that.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The `check-ids` target checks if commands are in the menus
or in the help.
The `src/ignored_menus.csv` and `src/ignored_help.csv` indicate what
does not need to be reported by the tools. It was initialized with the
current state of missing things, and can serve as a reference for what
commands need to either be documented or added to menus.
Fixes: #615
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Just the infrastructure to be able to build the statistics commands.
This originally exceeded the RAM section on DM42, which is surprising
(RAM, not Flash). It turns out that this was the size of the sorted
commands for the catalog, which was fixed.
Fixes: #495
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
When the argument describing the variable is a text, interpret that as
a file path on the disk. By default, data is stored in in a directory
named `data`, which will be created if necessary. For example, you can
use `3 "foo.48s" STO` to store the value `3` in a file named
`data/foo.48s` on disk.
How the file is stored depends on the extension given to the file:
* For `.txt` files, the object is stored as text
* For `.48s` files, the object is stored as DB48X source code
* For `.48b` files, the object is stored in binary format
* For `.csv` files, the object is stored in comma-separated format.
The binary format used for `.48b` includes a 4-byte magic number
identifying a DB48X format, and a 4-byte checksum used to ensure
binary compatibility between the firmware and the disk format.
At least during early days of development (prior to 1.0), it is quite
unlikely that the binary format for one version of the firmware would
be readable or writable by another version. If you need to recover
data from another version, you need to install that version and save
the object again in `.48s` (text) format.
Fixes: #375
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Implement a `debug_printf` that shows something on the screen, and a
`debug_wait` to wait for a given delay or a key.
Fixes: #541
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The `equation` type does not really represent equations (it may)
but arithmetic expressions.
Fixes: #518
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The generated font files contained an ID that could depend on the
configuration settings for the build. That caused the font file on
DM32 to be incorrect, which caused a crash when editing text.
Fixes: #458
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
This is a very basic implementation of unit objects.
Unit objects are treated as equations where the outermost object
is an ID_mkunit operator.
Fixes: #16
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Allow images in the source markdown files, but skip them on calculator
Note that we need to skip them at runtime if we want to be able to
have them in the GitHub file correctly.
Fixes: #438
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
This is mostly to validate the sanity of that build option
(a compilation bug was actually fixed).
Fixes: #432
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The name `simulator` is both long and non-descriptive.
Since the `db48x.pgm` and `db48x.pg5` cannot be confused with either
`db48x.app` (macOS), `db48x.exe` (Losedows) or `db48x` (Linux/BSD), it
seems safe to rename the simulator as `db48x`.
Also always build the files with lowercase names.
Fixes: #417
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Implement a really basic algorithm for integration evaluation.
This divides the integration surface by two every time.
This appears much less efficient than the integration done by HP calculators.
Fixes: #42
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The PNG image files are easy to generate from Keynote, but getting
from there to the file used in the simulator build was still manual.
Generate the target files automatically from the Keynote output.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
In case we want to build on some other platform, make it easier to
copy the file. Also makes it possible to use rsync instead.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
In order to properly distinguish the DM32 and DM42 builds, call
the DM32 variant 'DB50X' (both for program and QSPI file).
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
We are now reaching the point where we need to use that option to fit
on the DM42. The time has come to switch to `-Os` to compress the code
a little.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Graphic objects (GROB in RPL parlance) represent bitsmaps of arbitrary
size. They can be used to represent the screen or any other graphic
surface.
Fixes: #30
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The tag type is used to add a label to any arbitrary object.
It is parsed as `:Label:object`, and renders the same, except on the
stack where it renders as `Label:object`.
Note that the HP48 renders a label with an extra space. The space is
apparently gone on the HP50.
Fixes: #21
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
This commit implements comments that are preserved in the source code.
A comment begins with `@` and ends with the end of line.
It acts as a no-operation during execution.
It is rendered beginning with a new-line.
This commit also adjusts various issues related to rendering of
newlines and indentation in loops or blocks.
Fixes: #94
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The dmcp code is moved to a submodule, with its own BDS 3-clause license.
The DB48X code uses DMCP, but is not derived from it.
The GPL license will provide better protection against derivatives with
proprietary additions that are not contributed back to the community.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Implement `if` `then` `else` blocks, as well as the `iferr` variants.
Being able to test `iferr` also required implementing several
secondary error-management commands, like `errm`, `errn` and `doerr`.
Fixes: #290Fixes: #291
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Add support for DMCP5 and DM32 build
This is not perfect at the moment. Some glyphs, like the complex-i,
are missing from menus or the help display, as well as from the
editor font, but show on the stack font. This is rather weird.
Displaying some menus, like the STATS menu, cause a crash in
what appears to be sparse_font::glyph.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
