• You are here:  
  • Home
  • newRPL News

Details

After a long silence due to extensive code reorganization and integration with the user interface, things are coming together nicely.

Now there is a Qt-based simulator that shows a screen identical to that of a 50g, and allows the user to interact with newRPL exactly as it will be seen on real hardware. This will allow users to test-drive the user interface and provide feedback.

As of today, the command line editor is rudimentary but allows entering numbers in the stack. The keyboard system is completely customizable, and while not completely implemented yet (only a few keys have handlers right now), it's ready to receive individual key handlers.

There's 2 layers of keyboard handlers: custom handlers and system defaults. There is a system variable that tells whether the system is showing the stack, PICT, a form, or within the command line editor, etc. This allows handlers to react to the context. Handlers can be installed for a specific context or for all contexts, and for specific key messages: key down/up, key press, long key press, and all their shifted combinations.

In this way, a key handler can be installed for example for the right cursor key, unshifted, when the context is the stack only, and perform SWAP (this is the default). A different handler can be installed for the same key, when the command line editor is open, and move the cursor right, for example.

As an advanced example, the Enter key could be customized for the stack context only (when no command line is active), and make it do something different than DUP. All this without interfering with the Enter function within programs, the command line, etc.

There will be no limit on how many handlers the user can install. Each handler will have a context, an associated key and the action object. The system will scan through the list of handlers and execute the first one that matches the context/key combination.

When a key is pressed, the system will look for a variable '.KeyTable' (this name is subject to change). This variable will be searched for from the inner local environments towards the root directory. All lists will be searched for until one has a match for the pressed key, otherwise a default system handler will be executed.

Any program can redefine keys just by creating a local variable. If the program doesn't create its own message loop, it can always store the list in its directory, or worst case modify the list in the root directory (for something more permanent).

An application with a form could change the Enter key to perform data validation when using the command line for an edit box, for example.

While there's still some work to do, the next demo is getting closer. The plan is to release it as soon as the code can function as a basic calculator with the 4 basic operations. More and more features will be added later. The demo is planned to be released for both the Qt simulator and for the first time as a calculator ROM.

 

 

Details

A new demo has been released!

There are many improvements under the hood in terms of stability and bug fixes that were discovered while running the benchmarks. As far as new commands, there is now support for "binary" operations on integers, through the commands B+, B-, B*, B/, BAND, BOR, BXOR, and BNOT. These new commands allow the manipulation of a normal number using bitwise operations, with the result constrained to a certain word size.

The "words" are considered signed binary numbers, so a selected word size of 8 bits is able to store 8bits + 1 bit of sign, with a nueric range from -256 to +255. The maximum word size is 63 (for signed 64-bit integers).

Also, the basic framework for the support of flags is included, although only a couple of system flags are currently supported.

More important, a new stack snapshot framework was created, which allows to take arbitrary snapshots of the stack and restore them at any time, creating the illusion of unlimited virtual stacks that the user can switch between. While the framework is in place, the virtual stack funcionality is not enabled in this demo. The demo uses the framework to implement a 10-level UNDO system. Using the pseudo-command UNDO in the command line, the previous stack will be restored. UNDO is a pseudo-command, as in it can be entered by itself in the command line, but not within a program.

Finally, test operations on lists now behave the correct way, returning a single true/false value.

This is likely to be the last console-based demo. The next demo will very likely be a GUI application showcasing the final user interface that the 50g version will have. This GUI application will also allow more rapid development of the user interface.

Details

While the command line editor is in the works, it's good to take some time and see how everything else is working.

To test drive the new RPL core, the N-Queens benchmark code was executed in a couple of different configurations, and the timing under newRPL and the normal userRPL firmware was compared.

A second benchmark was developed based on a slowly converging series, which was executed on the 50g and under newRPL as well, but this time using different arbitrary precision values.

For a more extensive discussion of the programs utilized and their peculiarities, see this discussion:

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

 

The results are in. The speedup factor varies in each case, but it's safe to say that the expected speedup is 100x for number-crunching applications, around 200x for applications that use mainly the stack and integer numbers, and around 400x when using lists.

 

Algorithm userRPL newRPL Speedup
N-Queens - Original w/lists 90 s 0.197 s 457x
N-Queens - In-stack recursive 29.7 s 0.101 s 294x
N-Queens - In-stack optimized 22.6 s 0.106 s 213x
Series - 12 digit precision 87.4 s - -
Series - 36 digit precision - 0.893 s 98x
Series - 108 digit precision - 1.615 s 54x
Series - 1008 digit precision - 10.843 s 8x

 

Details

newRPL running the N-Queens benchmark on the 50g hardware is old news. We published some very early benchmarks in the article Running on 50g hardware.

But back then the newRPL core was running under the HPGCC3 environment, and without support for real numbers yet.

Now we introduce the first test run of the same benchmark running as an independent firmware. The average time for 10 runs is 226 ms at the normal speed for newRPL (normal speed means the first 500 ms running at 6 MHz, then switches automatically to 192 MHz until the code finishes).

This is running with the final version of the memory manager, a real garbage collector, among other things. While some optimizations in the RPL core are possible, this speed of execution is satisfactory.