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>
Reset the vertical font positions in the table to what they were initially,
add -y option to ttf2font to perform the adjustment in code.
This preserves the relative positions of lowercase 'a' and 'g' much better,
and allows the guides in the font editor to show at the right position.
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>
It does not seem to do much of a difference in terms of performance, and we are
really not wanting to have multiple inlined variants of the same function.
For example, draw_stack used to take 5K, it's down to about 1K.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
This is distantly derived from the help system I implemented for newRPL, but the
low-memory condition on the DM42 means we try to do everything without
allocating any memory.
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>
This second pass redesigns how template parameters are used:
- The graphics class itself is no longer a template
- The color, pattern and surface all take a template BPP
- Specializations are put "at the right spot"
This makes it more natural to have mixed-BPP operations that share a number of
types, like coordinates, points, rectangles.
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>
This required a few adjustments here and there, like headers that were not quite
C++-ready.
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
