There are some slight differences between the structure of the DM42
program and the structure implemented here. Not sure whether the
differences matter, but better follow a known-good model.
Also add missing DMCP critical section functions that appear used
in the DM42 code: `sys_critical_start()` and `sys_critical_end()`.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
This makes it easier to inspect RPL objects from debugger
For example, in `lldb`, you can use:
```
p obj->debug()
```
And this will show the content of the object as rendererd by the runtime.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Various portability fixes to help building on Linux.
This includes a pre-build Intel binary library for Linux x86_64.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
To ease debugging, add a %t format turning RPL object pointers into their text
rendering while tracing.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The `-w` command-line option takes a delay in millisecond between keystrokes.
Running slower minimizes the chances of a sync issue between the RPL thread and
the test thread. However, this mechanism is still not robust. I need to find a
reliable way to identify when the RPL thread is done processing the input from
the test thread.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The RPL thread now sends a -1 key repeatedly until the main loop exits and saves
the state.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The application dialog is in a loop processing keys, so send a special "exit"
keycopde (-1) to force it out.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The `QSettings` class is only used to store the path to the actual state.
The use of the file dialog seems to cause some trouble with the current working
directory, and this impacts the display of the help file.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The MainWindow::pushKey() method can be called from the test thread.
Therefore, we need to use emit to update the window, otherwise we end up with a
crash in the long run.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Two representations for fractions, one for small value of numerator and
denominator, one when both values are larger.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Various pieces of code, essentially equivalent to one another, were implemented
at various places to write into rendering buffers. Replaced all this ad-hoc code
with a single implementation in the renderer, which not only simplifies things
quite a bit, but also allows us to write in the scratchpad without a risk.
Also fixed a problem with the runtime::scratchpad() function returning the
beginning of the scratchpad instead of its current position, which was
inconsistent with a usage that assumed it moved with runtime::allocate(). This
enables a called function to use the scratchpad itself, while its caller also
holds something in it. This is necessary for the rendering of bignums, which
relies on long-division of bignums, and therefore can cause garbage collection,
while we may have the previous set of digits in an earlier part of the
scratchpad.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Having a sized type for bignum is more efficient both at runtime and in terms of
memory usage:
- At runtime, we don't need all the 7-bit masking and modulo-7 arithmetic
- In terms of memory, there is a cross-over at 63 bits, which is almost exactly
where it becomes uninteresting to do in-CPU arithmetic
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Implement do..until..end, while..repeat..end, start..next, start..step,
for..next, for..step. The latter two are not correct yet because we don't have
local variable lookup creation and lookup yet.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Also added more details on the description of the memory map, including planned
organization for local variables.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
A recurring pet peeve of mine: 'string' is an implementation detail.
We care that it's used to represent text
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Connect functions like sin, cos, tan, log, etc.
The bad news is that the bid128 functions take _a lot_ of space.
I thought that all of the Intel decimal floating point library was put in the
QSPI, but apparently, only some tables are. The total of the Intel
floating-point code is roughly 1.49M, the code in the calculator roughly 423K.
The code is rather on the large-ish side, with some large chunks of code that
are really hard to explain, like bid128_pow taking a whopping 42K, which is over
5% of my total memory budget (unless I want to take over the QSPI).
00000004 T __bid128_rem
00000024 T __bid128_from_uint64
00000048 T __bid128_from_int64
00000062 T __bid128_isInf
00000082 T __bid128_copySign
00000104 T __bid128_fma
00000108 T __bid128_sub
00000180 T __bid128_isZero
00000348 T __bid128_atan
00000348 T __bid128_tanh
00000352 T __bid128_erf
00000376 T __bid32_to_bid128
00000404 T __bid128_expm1
00000516 T __bid128_asin
00000544 T __bid128_log1p
00000572 T __bid64_to_bid128
00000576 T __bid128_acos
00000604 T __bid128_cbrt
00000608 T __bid128_mul
00000608 T __bid128_tgamma
00000640 T __bid128_exp
00000648 T __bid128_asinh
00000656 T __bid128_log
00000668 T __bid128_log2
00000676 T __bid128_exp2
00000684 T __bid128_log10
00000768 T __bid128_cosh
00000784 T __bid128_atanh
00000784 r bid_coefflimits_bid128
00000880 T __bid128_sinh
00000900 T __bid128_acosh
00000968 T __bid128_exp10
00001016 T __bid128_lgamma
00001048 T __bid128_erfc
00001628 T __bid128_class
00001752 T __bid128_round_integral_zero
00002004 T __bid128_quiet_equal
00002176 T __bid128_round_integral_nearest_even
00002740 T __bid128_to_string
00003208 T __bid128_to_int32_rnint
00003680 T __bid128_tan
00003708 T __bid128_cos
00003728 T __bid128_to_int32_xrnint
00003736 T __bid128_quiet_greater
00003740 T __bid128_sin
00003748 T __bid128_quiet_less
00003748 T __bid128_quiet_less_equal
00004400 T __bid128_hypot
00004440 T __bid128_to_binary128
00004700 T bid128_to_binary128_2part
00004864 T __bid128_to_bid32
00005484 T __bid128_to_bid64
00005876 T __bid128_fmod
00008430 T __bid128_sqrt
00008592 T __bid128_from_string
00010140 T __binary128_to_bid128
00017348 T __bid128_div
00024390 T __bid128_add
00029524 t bid128_ext_fma
00042058 T __bid128_pow
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Not sure I got this right, but better to see some voltage reading on the actual machine.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Add references to the UI fonts from font.h
Also add font::height() to compute the height of the font
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
This is a simple small-scale test that uses the new graphics routine to clear
the screen with a gray-scale pattern.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
If multiple consumers need to check if the screen has changed, a simple flag
does not do it. Instead, increment a counter that each client will be able to
check indepdendently.
This will be useful for an upcoming test framework
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
This is made a bit complicated by the fact that numbers can be represented in 6
integer types and 3 decimal floating-point types. So every operation must deal
with promotion.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
All the to-be-created-shortly operations like addition, etc, are not just
commands, but algebraic operations in RPL, so prepare for that
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
We can't really use it on the DM42 itself, because it has so
little memory (70K) that using it for recorders is a waste.
But for debugging on the simulator, it's really handy.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
I wanted to do something smart with QTimer, but it fails because they interact
with QT's event loop, making timers across threads annoyingly difficult.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
The two compilers disagree on how to disable a parameter.
Putting it as an attribute requires less typing anyway.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Remove "unused parameters" in dmcp.cpp, since most functions are only half-there
Remove format security warning on printf utility
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
Results for 1000 iterations:
- BID+USB: 3667ms (bid128)
- BID+Bat: 10091ms
- DBL+USB: 668ms (double)
- DBL+Bat: 1963ms
- FPU+USB: 43ms (float)
- FPU+Bat: 96ms
So we have close to two orders of magnitude between hardware FP and BID,
and a factor of 15 between double and float.
For 1M iterations on simulator:
- BID: 9847ms
- FPU: 172ms
- DBL: 240ms
So here, the ratio is ~50. And the simulator is roughly 370x faster than the
calculator, which we will need to remember as we implement complicated
or expensive algorithms.
Also, we will need to really prefer float wherever possible, since this is
processed in hardware, whereas I suspect that double is only software on that
CPU.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
