Joe-Bob says, "Check it out!"

  <URL:http://download.sourceforge.net/topaz/topaz-0.10.tar.gz>

Topaz 0.10 includes LOTS of new stuff.  Most importantly, it actually
_runs_code_!  You have to build the Op tree by hand -- no parsing --
but still, doggone it, it's nice to have 'hello world' run!

Here's the ChangeLog entry:

        Short list:
        * Ops are now generated from '*.ops' files using the new Perl
          program 'tools/genops'.
        * Compilation infrastructure works: UserCode objects can be
          created Op by Op.  See test_run.cc.  (No parsing yet.)
        * Runtime infrastructure works:
           > UserCode objects run.
           > Stack is flushed between statements.
           > Control structures nest.
           > Arbitrary cleanups can be registered (a la 'savestack').
           > Stack is of Values, not Scalars.  (duh)
        * Context (list/scalar) is supported, both statically
          (compile-time) and dynamically (run-time).
        * Command line processing works.
        * Debugging flags are available: '-Dt' and '-Ds'.
        * There is a beginning of diagnostics (warn and die), including
          '-w' and a framework for lexical warnings.
        * RealGlobScalar implements the equivalent of an SVt_GV that does
          _not_ have SVf_FAKE set -- i.e. it does aliasing when you assign
          to it.
        
        * Compatibility Note #1: I am no longer targeting Microsoft Visual
        C++.  The EGCS team have set themselves the goal of source
        compatibility with VC++, and they seem to already be most of the
        way there.  EGCS's support for MS's non-standard language features
        eliminates the final obstacle to our using it under Windows.

        * Compatibility Note #2: EGCS's standard library still doesn't
        quite have the hang of e.g. std::memcpy() vs. ::memcpy().  So you
        might have to tweak calls of <string.h> functions and other C
        remnants.
                
        Grody Details:

        * Inst classes implement run-time behavior of Ops.  Each
        compilation in progress has an arena for Ops and an area for
        Insts.  Once the Ops are all built, their compile() methods are
        called to create Insts in the Inst arena.  The Ops are then
        superfluous and can be deleted.  The Inst arena is then attached
        to the UserCode, _defining_ it.  At runtime, Insts are executed
        via their run() methods.  Insts are allocated sequentially from
        their arena, so there is usually no need for the equivalent of
        op_next.  (But heaven forfend an Inst multiply inherit!)

        * BasicInst.{hh,cc}: Some Insts are so basic that they don't
        necessarily come from corresponding Ops:
        NOP_Inst   (do nothing)
        EndInst    (stop a run loop)
        JumpInst   (low-level goto)
        MarkInst   (push a stack mark).

        * proto.ops defines prototype (test) ops for development:
        srcfile    (new source file)
        state      (new statement: flush stack, new source line)
        const      (constant value -- scalar only, for now anyway)
        glob       (*GLOBAL)
        glob_scalar ($GLOBAL)
        glob_array (@GLOBAL)
        glob_hash  (%GLOBAL)
        glob_code  (&GLOBAL)
        gethostname
        print
        keys

        * math.ops defines math ops:
        add, subtract, multiply, divide, modulo

        * Some template trickery simplifies the declaration of
        smart pointers -- ValuePtr is now exactly the same as
        CountedPtr<Value>.
        
-- 
Chip Salzenberg          - a.k.a. -           <[EMAIL PROTECTED]>
        "He's Mr. Big of 'Big And Tall' fame."  // MST3K

Reply via email to