octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Octave compiler


From: John W. Eaton
Subject: Octave compiler
Date: Wed, 8 Sep 2004 11:27:47 -0400

On  8-Sep-2004, Rob Vermaas <address@hidden> wrote:

| In our group we are currently working on a compiler for Octave. The 
| compiler translates Octave code to C++ code. The compiler is implemented 
| mostly in Stratego (see www.stratego.org).
| 
| It consists of the following packages:
|   - octave-front, the front-end, containing parser etc.
|   - octave-opt, the optimizer
|   - octave-tc, the type checker/inferencer
|   - octave2c, back-end
| 
| We are hoping to have a first release at the end of this month. This 
| release will have quite some limitations though, among others
|   - variables should not change types
|   - no eval/feval
|   - limited support for built-in functions
|   - no lists
|   - no streamoffs
|   - no int8/16/... etc. (as we based the compiler on octave-2.1.57)
|   - lots of bugs ;-)
| 
| If you are interested and want to check out what exactly we are doing, 
| it is possible to access the compiler packages at 
| https://svn.cs.uu.nl:12443/repos/octave/trunk/octave-top/.

What are the problems you face when supporting built-in functions?
The code for those functions already exists, so shouldn't you be able
to link to liboctinterp/liboctave and have nearly all of them work?

I looked at the parser, and it seems you have adapted Octave's lexer
and parser.  I think this is a good idea, as it makes little sense to
develop a separate parser from scratch.  However, the code in Octave
is likely to change, so if you fork your own version, you are likely
to have a maintenance problem in the future.  Would you like to help
introduce changes to Octave's parser so that it would be easier to
generate what you need without having to rewrite the actions part of
the paresr?  It migth be possible to do that now, without any changes
to Octave, by writing a new new class based on Octave's tree_walker
class (in src/pt-walk.h) that can take Octave's tree representation of
the input and emit whatever you need for your front end.  That way,
any changes to Octave's language in the parser/lexer would require
fewer changes to your code.

The front end appears to have a list of built-in functions and
variables.  How do you generate this list?  Would you like to
contribute or help write patches to Octave's build system so that you
can generate this information automatically for new versions of Octave?

Are you aware of other efforts to write compilers for Octave?  It
might be good to work together rather than have multiple projects.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]