Details

Published: 10 January 2016

The past:

It's been two years since the newRPL project was born. The first year (2014) was almost entirely dedicated to the basic RPL language core and its many objects. The second year (2015) saw the project user interface develop, thanks to a Qt GUI front-end, and also saw the project become usable as a basic calculator on the 50g hardware.

The present:

Currently there's ongoing work in the menus and command help systems. However, the help, as well as other messages in the user interface need to be easy to replace, in order to support multiple languages. Internationalization needs to happen before these systems operate properly, so there's a barrier preventing massive implementation of menus at the moment.

2016 and beyond:

The first challenge is to be able to easily define the menus, their commands and help. The simplest and more portable way is to define the menus as RPL lists, ready to be used by TMENU. In order to do that, a new stand-alone newRPL compiler is needed.

• The first task of 2016 is to make this new compiler work, and integrate it into the build process of the main projects. This will allow not only to define menus, but to include any other arbitrary RPL code in ROM.
• After that, the interactive stack is the next pending item to provide a more complete user experience.
• The command line is still lacking some refinement: cut/copy/paste, search and search/replace,
• Add the last few missing object types: tags and hex strings (or some equivalent arbitrary data object)
• Revisit all the commands already implemented for completeness and correctness.
• Implement more commands, the goal for 2016 would be to reach the 25% mark in the detailed project status

There's great challenges ahead. Now it's time to work on them. 

Details

Published: 17 August 2015

A while ago, a benchmark was developed based on a slowly converging series, which was executed on the 50g and under newRPL as well.

For a more extensive discussion of the program utilized, see this discussion:

http://www.hpmuseum.org/forum/thread-2368.html

Originally, the benchmark compared userRPL with newRPL, but now that same benchmark will be used to compare the old newRPL results using the mpdecimal library versus the new decimal library. The userRPL result will be left there for comparison.

For the new library, two numbers are reported, the first one as perceived by the user including a period at slow speed, and a second one at full speed. The original results were reported before the clock management features were in place, therefore they were executed at full speed. Another difference to consider is that the old decimal library was most efficient when precision was a multiple of 9 (hence the choice of 36, 108 and 1008 digits). The new library is most efficient when the precision is a multiple of 8, so selecting 36 digits causes 40 digits to be used internally, with 4 digits being discarded at final rounding.

At 1008 digits, the speedup is almost 2x versus the old library, confirming that the extra effort of writing a new variable precision library paid off.

Back to comparing with classic userRPL, the speedup at the same 12-digit precision is 130x, while using the default 32-digit precision the speedup is still 118x.

Details

Published: 07 January 2016

• An IDENT will be looked up as a variable, and the actions will behave as in the VARS menu. If it happens to be a directory name, then it will look like a directory does in the VARS menu. Long-press will display a preview of the contents of the variable.
• A UNIT object with a numeric portion equal to 1 will be displayed without the numeric portion, and it will behave as if it was in the UNITS menu.
• A command will work as expected, but also help will be automatically displayed upon long-press.
• All other objects will be decompiled for Display, executed for action, and no help will be provided.

When the item is a list, there's 3 main components:

Display:

It can be a single object or a list with 2 elements. When it's a single object, it will behave as follows:

• A program will be executed, and it must leave one object on the stack, which will take its place as the Display object.
• A GROB will be displayed as-is in the soft menu.
• A string will be displayed without quotes
• A UNIT with a quantity of 1 will be displayed without the numeric part.
• All other objects will be decompiled and the resulting string shown on the soft menu

The display object can be a list with 2 elements: { Display Decoration }

The Display object works as described above, while the decoration must be an integer that indicates if the element has to be displayed normally, inverted, as a directory, with a "checked" checkmark, with a "unchecked" checkmark, etc.

Action

The action object will be executed when the user activates the soft menu. It can be an object, or a list of 3 or 5 components:

Action (all key combinations cause the same action)

{ Normal Left-Shift Right-Shift } (a different object will be called when the user presses the item in each shift state)

{ Normal Left-Shift Right-Shift Left-Hold-Shift Right-Hold-Shift } (a different object will be called when the user presses the item in each shift state, in this case it also distinguishes between shift and shift-hold presses)

When an action object is executed, the following rules are followed:

• A single command or operator will be executed, or its name will be inserted in the editor if the command line is active
• A UNIT object provides various actions depending on the shift used, similar to the UNITS menu.
• An IDENT object has various actions, similar to variables in the VARS menu.
• All other objects will be XEQ'ted.

Help

The help object can only be a string. The string will be displayed when the user long-presses the soft-key.

Optionally, the item may not have a Help object (defined only as { Display Action }).

So where's the extra flexibility?

The display object can be a program! This allows to programatically change a menu item appearance.

Details

Published: 15 August 2015

The new decimal library is in place, and the new firmware now feels a lot more responsive when using trig functions, getting an instantaneous response, when before there used to be a slight delay.

In order to measure the speed of the new library, a new benchmark was prepared that uses transcendental functions and compares the speed to the 50g doing the exact same calculation. The same program was executed on a 50g with stock firmware and a 50g with newRPL. The objective of the program is to compute 100 points of a damped oscillatory function. The function in question is A*e^(-w0*c*t) * SIN( sqrt(1-c^2)*w0*t). In both cases the parameters used to run the program were: A=10, c=0.3, w0=1.25. The points are calculated from t=0 to 10 seconds, with a step of 0.1. The resulting userRPL program was:

<< -> A c w0 << 0 10 FOR t A c w0 t * * NEG EXP * 1 c DUP * - [SQRT] w0 * t * SIN * 0.1 STEP >> >>

And it was executed by a wrapper that gave the parameters:

<< 10. 0.3 1.25 OSC >>

Here are the results of the benchmark:

newRPL has 2 results for each test. The left one is the time "as the user perceives it", including the first 300 ms running in slow mode, then switching into full speed. The second number is "raw throughput", measures after the CPU is running at full speed, and gives a good idea of the computing power.

This benchmark executes about 700 multiplications, and 300 transcendental functions (100 SIN, 100 EXP and 100 SQRT) in that time. At comparable precision, newRPL is about 9.5x faster than the stock firmware. At around 120 digits of precision, newRPL finishes the task in about the same time as the stock firmware.

Unofficially, the same program was executed on an older version of the firmware still using the mpdecimal library. At the default precision of 36 digits, execution took about 8 seconds but can't be reported for 2 reasons: the ROM didn't have proper TICKS support therefore couldn't measure time accurately, and because it produced incorrect results, so it was disqualified from the comparison (although the number of operations was the same (despite having a bug somewhere), so times were indeed comparable).