*fix Core Status
From OpenRPN
[edit] May 2006
Successfully integrated Hugh Steers's [BCD20 library] in *fix core. Paul has integrated BCD and binary numbers in the same core. For now, scalar representation can be switched with BINARY and BCD. We'll implement that as a flag later.
The current (as of May 19) code has been compiled on an ARM-based system (although not with eCos) and runs correctly.
We all understand that memory management is of utmost importance. Although the code currently uses reference counting, we may want to replace it with a classical mark & sweep garbage collector in the near future.
The parser is now stack-based instead of recursive. The next step is the execution engine; it will bring us much closer to a Forth engine.
[edit] April 2006
[OpenRPN] now has a [Sourceforge project]. We made the decision to go with eCos RTOS, which will need to be ported to the version of ARM we are using.
StarfixCoreSpecifications *fix core specification is on-going.
An alpha version of *fix core has been committed to the [subversion] server on Sourceforge. This version is built on the work of Jonathan's Javascript version.
The version compiles on Linux, and I have a report of successful compilation on Visual C++. It is now a simple command-line application.
It uses the native double precision library, and the goal is to plug-in Hugh Steer's BCD library. We want to keep the ability to use either one of these floating point implementations (speed vs. precision tradeoff).
The current version of the core is pretty crude, but has a lot of the functionality: most stack operations are there, most list operations are implemented. Strings still miss some important commands, like SUB. Binary integers are implemented using the native long long format. Four operations are supported.
Basic infrastructure is there for exception handling.
Local variables are supported, but for now have dynamic scope instead of lexical scope (much easier to implement :) ). This will have to be fixed.
The current version of the core looks up every function call in the dictionary. Work is in progress to do most lookups at parse time, so that execution is faster.
There is nothing there to manage the memory, and it leaks like crazy. We still have to decide if we will use a garbage collector or if we manage the memory manually. Being lazy, a garbage collector may be good. We need to see the impact on performance, memory usage and portability to eCos.
Parts of the core still use STL (lists, map). This is convenient to get something to work quickly, but needs to be rewritten without STL.
The goal for now is to strenghten the core rather than implement all the functionality, make it robust and a reliable foundation for the rest of the work.
