newRPL project status

[Claudio L.]

Hello,
For those interested, here's a link to the project website to track our status...

http://hpgcc3.org/projects/newrpl/project-status

Claudio

[pdo]

Excellent! I'll be following it with interest. Do you expect to have any code/doc publicly available soon?

Paul Onions

[Claudio L.]

Yes, the plan is to cleanup the code and upload it very soon.
We could release what we have now, but with integers only there's not much you can do (though it was enough to run the N-Queens benchmark for fun, see http://hpgcc3.org/8-newrpl-news/24-runni...g-hardware).
The idea is to have something that people can actually test and play with, so perhaps we'll implement real numbers and then release the code. I'd say we are still a couple of months out from releasing the first alpha code.
Documentation is making slow progress, but at this point many things are changing in the core API, so there's no point in putting too much effort into it until things stabilize a bit.
The project was already created in sourceforge, which is where the sources (and binaries) will be released, it will all be announced on the website linked in the original post (check the "latest news" on the right for brief posts regarding our progress, so we don't pollute this forum).

Claudio

[Ailurus]

The project status page states user interface as being part of the development. Does this mean a whole new interface or just copying what's been done before? Just curious.

[Claudio L.]

(04-09-2014 11:53 AM)Ailurus Wrote:  The project status page states user interface as being part of the development. Does this mean a whole new interface or just copying what's been done before? Just curious.

The objective is to create a new firmware, so everything needs to be done from scratch. And I mean EVERYTHING.
We are currently focusing exclusively on the RPL execution core, but very soon the core will be stable enough (not all commands will be implemented, but enough for a regular scientific calculator, let's say), and we'll begin work on the other areas in parallel.

The discussion about the interface can start now if you want (why not?).
Here's a few points that I'd like on a good user interface:

* The main place is the stack (not some root menu with icons with the stack as an application). I like to turn on the calculator and be ready to input numbers instantly.
* Soft menus at the bottom: Since we are aiming to the 50g hardware, we should adhere to this format. But some variations are possible, what about having 12 softmenu keys? This would include the APPS, MODE, TOOL, VAR, STO, NXT keys as additional soft menus under certain cases (this idea was somewhat implemented in the hpgcc3 GUI module, but nobody ever used it I think). These 6 additionals could be for example a VARS menu permanently shown, while the "normal" 6 soft keys are used for other menus.
* Status area needs to be reduced to a minimum or removed (perhaps a pop-up status area when you press-hold a key for a long time, etc).

At this point all ideas are welcome, so set your imagination free.

Claudio

[Ailurus]

(04-10-2014 01:13 PM)Claudio L. Wrote:  I like to turn on the calculator and be ready to input numbers instantly.

This is important, it's one of the few advantages using a calculator over a smartphone.

I'd like lower case letters to be the default, neither textbooks or I write "X, Y, Z" and writing "if, and, for" over "IF, AND, FOR" will make my calculator look less like a 70's relic. It would be better for emulation and writing from a computer, programs look alot better and it makes sense if you're going to implement new rpl for something but the HP 50g in the future.

[brouhaha]

(03-26-2014 02:27 PM)Claudio L. Wrote:  For those interested, here's a link to the project website to track our status...

http://hpgcc3.org/projects/newrpl/project-status

Claudio

The status has an item "memory manager" which says "Needs support for MMU on target". Why is an MMU required? Will it still be possible to run on a platform with no MMU?

How about an ARM Cortex-M3 with no MMU, 960KiB of flash, and 128KiB of RAM, 43 keys, and a 2.7-inch 400x240 pixel black and while LCD? I expect to be able to make prototype hardware available to developers soon.

[David Hayden]

(04-12-2014 03:33 AM)brouhaha Wrote:  The status has an item "memory manager" which says "Needs support for MMU on target". Why is an MMU required? Will it still be possible to run on a platform with no MMU?

The idea is to put the different memory areas (tempOb, data stack, return stack, temporary variables) at distant locations from each other in the address space. When one area needs to grow we'll tell the MMU to map a page to it. This will be much faster than the traditional RPL method of packing memory areas next to each other and possibly moving them when one area needs to grow.

Memory management is isolated in the code so I suspect we could do it in a system without an MMU also.

Dave

[Claudio L.]

(04-12-2014 03:33 AM)brouhaha Wrote:  How about an ARM Cortex-M3 with no MMU, 960KiB of flash, and 128KiB of RAM, 43 keys, and a 2.7-inch 400x240 pixel black and while LCD? I expect to be able to make prototype hardware available to developers soon.

Our "base" hardware target has 512 kbytes of RAM. Although the core itself works with very little ram (right now the demo uses about 64 kbytes), it will be hard to handle the user interface with that little amount of ram, but I guess it could be done.
The amount of flash is also quite scarse, since the tables needed in ROM for transcendental functions will be close to 300 kbytes alone. The core right now is at 133 kbytes, without transcendental functions (and without 95% of the features we want!!!).
MMU is not a show stopper, since you could have rigid partitions in RAM and avoid the use of the MMU. The problem is that the way the system is designed you'll have fixed maximum stack size, fixed maximum return stack size (so recursion will be limited).
for example:

<< 1.0 1 1e10 START DUP NEXT >>

would fail when your data stack partition is full, even though your TempOb only contains one object (the program above).
The MMU helps us compensate for that, and make better use of the little RAM we have.

Claudio

[Claudio L.]

(04-11-2014 07:24 PM)Ailurus Wrote:  I'd like lower case letters to be the default, neither textbooks or I write "X, Y, Z" and writing "if, and, for" over "IF, AND, FOR" will make my calculator look less like a 70's relic. It would be better for emulation and writing from a computer, programs look alot better and it makes sense if you're going to implement new rpl for something but the HP 50g in the future.

Interesting. It could easily be done by making the commands case-insensitive (we still need to accept the capitals since we are aiming to be source code compatible with existing code), so it's no big deal to implement it.
My only concern is that we are aiming to be compatible with existing code, and creating all these extra reserved words, any existing code will give a syntax error when you try to compile it if you use variables that are now reserved words.
I can easily see myself using a variable named 'exp' or 'arg' for example.

Is this a tradeoff worth exploring?

[Ailurus]

(04-12-2014 09:00 PM)Claudio L. Wrote:  Interesting. It could easily be done by making the commands case-insensitive (we still need to accept the capitals since we are aiming to be source code compatible with existing code), so it's no big deal to implement it.
My only concern is that we are aiming to be compatible with existing code, and creating all these extra reserved words, any existing code will give a syntax error when you try to compile it if you use variables that are now reserved words.
I can easily see myself using a variable named 'exp' or 'arg' for example.

Is this a tradeoff worth exploring?

It depends. I think using reserved keywords like "exp" or "sqrt" should be discouraged as they'll make reading the program a bit confusing and raise questions like "does exp work like expected or is it something I've written?". However, newRPL should be appealing to former RPL-programmers and having to read 100 pages documentations on "port your program to newRPL" would not appeal to anyone. I would take it into account but decide on a later stage.

I think ideas like the 12 key softmenu is worth trying out, there should really be a release later on where ideas can be implemented and tried out.

Another feature I've missed from the 50g is a help system, I may be mistaken but from what I understand, the built-in help only works for the CAS. This is also on a later stage and it takes time to do it. I can help out on any writing and testing where it's needed.

[tuns1999]

Interesting project Claudio,

As much as it is good that HP is back to releasing new calculators, and there is a lot I like about the prime, the lack of RPL made me lose interest.

The 50g with newRPL sounds much more interesting to me.

Just curious are you aware of the RPL/2 project? Its seems like it is aimed more at desktop use for POSIX systems as opposed to handheld hardware but it seems fairly mature and actively developed.

I honestly don't know much about it but I plan to install it on my Mac and check it out.

I am guessing that there must be a great deal of work in this project that would be useful to newRPL.

[Claudio L.]

I didn't look at RPL/2, I saw its webpage a long time ago, and it seems to be a desktop console application, not really a calculator environment, so the final objective is completely different.
newRPL is not just a scripting engine, it's the whole environment, finished and installed on dedicated hardware.
That makes our project diverge from other projects quite rapidly, so we can't reuse much from anybody. Even the core of the RPL engine will be very different on a Desktop computer (with huge amounts of RAM) versus a small embedded environment.
We also had available RPL32 from David Hayden, but we couldn't use it because of similar issues: completely different memory management was required (besides the language differences).
In any case, stay tuned, we are getting close to a first alpha mini demo (accidentally very similar to what RPL/2 looks like from screenshots). Of course this demo will have nothing to do with the final user interface. It's just to release something people can play with, provide feedback and at the same time see that this project is getting serious and advancing quite rapidly.
Work on the target hardware will commence very soon, the goal would be to have an alpha demo running on real hardware published by the end of the year.

Thanks for your interest on the project.

Claudio

[Han]

The most recent demo (version 4) seems to be a PC application. Are there any news on a calculator demo?

[Claudio L.]

(01-07-2015 09:21 PM)Han Wrote:  The most recent demo (version 4) seems to be a PC application. Are there any news on a calculator demo?

As of right now the command line editor is not ready. The demo I have displays the stack properly and runs various versions of the N-Queens benchmarks and other short programs at the press of certain keys.
But you can't type in anything yet, so it's not much fun for people to play with.

Claudio

[Ailurus]

I've been following the project from the start and I wonder if there is any way to help out. Is there some mailing-list or something, any way to contribute?

[Claudio L.]

(02-28-2015 12:23 PM)Ailurus Wrote:  I've been following the project from the start and I wonder if there is any way to help out. Is there some mailing-list or something, any way to contribute?

Yes! we have mailing lists in sourceforge, there used to be a lot of discussions there in the first part of last year (when the project started). But now that it's just me there hasn't been any posts in a long time (I see no reason to talk to myself).
Your help is welcome! Send me an email at [my first name] at hpgcc3.org and we can discuss how your skills can be put to good use.

A little bit of status update for all readers:
Right now the core has been mostly "frozen" for 3 months, while I'm developing a Qt simulator that can compile and run the firmware natively on a PC. This is needed (in my opinion, but since I'm a one-man team now, it's the only opinion I hear) to accelerate debugging and development of the most "difficult" parts. The UI mainly needs visual feedback, and the cycle "compiling/flashing/watching-it-crash/trying-again" is too time-consuming.
So far, the simulator already executes the firmware on a simulated LCD (grayscale and monochrome emulation, still working on adding the annunciators). There's also timers simulation and some low-level cpu API (mostly dummy functions). Next step is to provide keyboard simulation (which hopefully will be ready in a couple weeks).

To achieve this, the whole firmware tree was reorganized so it can be compiled from within Qt Creator: Opening the "simulator" project file should compile and execute the simulator, while opening the "firmware" project should cross-compile and leave a rom image. All on the same source tree, and using the same IDE.

This is being done so that anyone can get the source code, install Qt Creator and be ready to develop in 5 minutes. Hopefully this will attract more developers to the project. Also debugging in the simulator will make things so much easier for everybody. Since the whole tree will be changing, this will only be released to the public repository when it's ready, in one shot.

Nowadays we have 5 main battlefronts, and the project needs help in all of them:

1. Simulator:
   • Keyboard simulation
   • New/Open/Save RPL sessions.
     
2. User Interface:
   • Command line editor
   • Customizable keyboard handlers
   • Soft menus
     
3. RPL Core:
   • Symbolic rules engine
   • Vectors and matrices
   • User interface-related commands
   • A loooong list of commands and features, which are more-or-less independent of each other and can be developed in separate libraries by different people at once without stepping on each others toes.
     
4. Documentation:
   • Documentation is almost non-existent (just a couple of documents on the website), so there is a huge amount of work to be done here.
     
5. Testing:
   • Test the compiler with all sorts of malformed input to see how robust it is (try to break it/crash it).
   • Test the decompiler with malformed objects to make sure it doesn't crash.
   • Take every single command, review its code and test it for robustness in multiple possible scenarios. Perhaps create a battery of tests for RPL language.
     

There's of course a natural order of things: the simulator will help in developing the user interface, which will in turn help with testing. The symbolic rules engine will unlock work on most other symbolic commands (which will become sets of rules mostly).
Matrices haven't been implemented yet, since the idea is to have a single matrix object that can contain reals, complex or symbolic objects. So symbolics needed to be ready first.

This may serve as an invitation for others who feel they have the skills to help with any of these areas to join. Just send me an email.

Claudio