HP Forums

Full Version: OpenRPN *fix core release 0.1
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

All,

I'm happy to announce the first release of *fix core, the RPL-like engine that will one day power OpenRPN calcs.

sfix-core-0.1.tar.gz

This is a pre-alpha release. We've been toying around with Paul, and this is very far from anything product like. The C++ infrastructure is far from final as far as memory management is concerned. It lacks exception handling, and is absolutely not ready to be embedded and may still have a lot of bugs.

On a desktop Linux machine, though, it's already fun to use. We have integrated Hugh Steer's BCD20 library, and we can switch between native (binary) floating point and BCD with a flag.

Paul has also added a lot of HP16C-like functions.


It should compile on any Linux box, Cygwin and probably Visual Studio with little elbow grease.

Feedback and (constructive) comments appreciated. I know it's not a Forth core, I know it's far less memory efficient than RPL, but I know also we've been two developers only, writing code as a hobby after a busy day at work.

The Sourceforge project also has a mailing list for discussing the core implementation.

Come on in and join the fun!

-- alain.

Edited: 14 July 2006, 2:08 a.m.

very interesting.
Just one remark: the archive is a tar (.tar), and is not zipped (.tar.gz ).

Eric.

Builds with a simple 'make all' under MacOS X and appears to be working:
Running the tests via "test.sfix" READFILE reports "PASS" for everything...

Yet simple manual tests can produce very weird results or crashes, for example:

sfix> CLEAR 2 NEG SQRT
1: 0

sfix> CLEAR 1 0 /
1: 0

sfix> CLEAR 0 0 /
1: 0

Starting program: /Users/chris/Desktop/sfix-core-0.1/sfix 
Reading symbols for shared libraries . done
sfix> CLEAR 0 0 R->C SQRT

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000014
0x0000e780 in ObjectHandle::toString (this=0x430ff0, env=0x400150) at Object.cc:160
160 obj->toString(env);
(gdb) where
#0 0x0000e780 in ObjectHandle::toString (this=0x430ff0, env=0x400150) at Object.cc:160
#1 0x00005634 in Stack::toString (this=0x42f600, env=0x400150) at Stack.cc:46
#2 0x0000ed58 in sfprint (env=0x400150, me=0x4032d0) at System.cc:92
#3 0x00013a24 in interpreter (env=0x400150, lh=0x400150) at Interpreter.cc:47
#4 0x0000b044 in main (argc=4394992, argv=0x400150) at main.cc:96

Quote:
Builds with a simple 'make all' under MacOS X and appears to be working:

I've done most of my work under MacOS X so it isn't a surprise it works :-) There have been incompatabilities between my Mac and my Linux box. Hopefully resolved now...


Quote:
Running the tests via "test.sfix" READFILE reports "PASS" for everything...

There should be exactly 6 fails. All near the start. The tests mostly validate the HP16C functions at the moment. A lot more effort is required on this front.


Quote:
Yet simple manual tests can produce very weird results or crashes, for example:

Yeah, the complex stuff hasn't been done yet. Likewise much of the error checking. The bulk of what is currently implemented corresponds to SysRPL (i.e. limited integrity checking).

Alain can deal with the core dump :-)


Regards,

Pauli

Oops. I was trying to inflate the trafic on the Sourceforge project :-)

Fixed.

Quote:
sfix> CLEAR 2 NEG SQRT
sfix> CLEAR 1 0 /
sfix> CLEAR 0 0 /
sfix> CLEAR 0 0 R->C SQRT

Like I said, this is pre-alpha version :-)

The complex arithmetic doesn't work yet, only R->C and C->R for the moment and some C::ADD, C::SUB, C::MUL, C::DIV, C::NEG and C::ABS functions.

Exception handling is almost non-existent. At least the divide by zero doesn't crash ... :-)

The arithmetic stack will undergo big transformations in the near future: for now, the dispatch for "+" is done in C++. One of our objective is to write the dispatch in *fix itself, yielding a much more flexible environment.

Thanks for the report.

-- alain.