Octave compiler

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Octave compiler

Rob Vermaas
Hi there,

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/.

That said, I have a small feature-request (sorry if this is the wrong
list to post this on). We are using mkoctfile in the back-end of the
compiler. At the moment I'm patching mkoctfile manually to allow .oct
files to be passed as object files when compiling a stand-alone
application. I was wondering if it is possible to add this to the
mkoctfile in Octave itself, or are there any objections to this? I have
attached a patch to this email.

greetings,

Rob Vermaas




--- octave-2.1.58/mkoctfile.in 2004-09-02 03:28:49.000000000 +0200
+++ octave/mkoctfile.in 2004-09-08 10:37:02.000000000 +0200
@@ -106,6 +106,10 @@
       file=$1
       objfiles="$objfiles $file"
     ;;
+    *.oct)
+      file=$1
+      objfiles="$objfiles $file"
+    ;;
     -d | --debug | -v | --verbose)
       dbg=echo
     ;;
@@ -172,6 +176,7 @@
                             .f    Fortran source
                             .F    Fortran source
                             .o    object file
+                            .oct  object file
 
 EOF
       exit 0
Reply | Threaded
Open this post in threaded view
|

Octave compiler

John W. Eaton-6
On  8-Sep-2004, Rob Vermaas <[hidden email]> wrote:

| That said, I have a small feature-request (sorry if this is the wrong
| list to post this on). We are using mkoctfile in the back-end of the
| compiler. At the moment I'm patching mkoctfile manually to allow .oct
| files to be passed as object files when compiling a stand-alone
| application. I was wondering if it is possible to add this to the
| mkoctfile in Octave itself, or are there any objections to this? I have
| attached a patch to this email.

Why is this needed?  A .oct file is not an object file.  It is usually
a shared library object, and it is intended to be loaded by dlopen (or
a similar mechanism).

If you want to link in the code for a .oct file directly to an
application, wouldn't it make more sense to do something like

  mkoctfile -c my_oct_file.cc
  mkoctfile [other options and files] my_oct_file.o

?

jwe


Reply | Threaded
Open this post in threaded view
|

Octave compiler

John W. Eaton-6
In reply to this post by Rob Vermaas
On  8-Sep-2004, Rob Vermaas <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Octave compiler

Rob Vermaas
In reply to this post by John W. Eaton-6
Hi John,

John W. Eaton wrote:

>On  8-Sep-2004, Rob Vermaas <[hidden email]> wrote:
>
>| That said, I have a small feature-request (sorry if this is the wrong
>| list to post this on). We are using mkoctfile in the back-end of the
>| compiler. At the moment I'm patching mkoctfile manually to allow .oct
>| files to be passed as object files when compiling a stand-alone
>| application. I was wondering if it is possible to add this to the
>| mkoctfile in Octave itself, or are there any objections to this? I have
>| attached a patch to this email.
>
>Why is this needed?  A .oct file is not an object file.  It is usually
>a shared library object, and it is intended to be loaded by dlopen (or
>a similar mechanism).
>
>If you want to link in the code for a .oct file directly to an
>application, wouldn't it make more sense to do something like
>
>  mkoctfile -c my_oct_file.cc
>  mkoctfile [other options and files] my_oct_file.o
>
>  
>
The issue was that I wanted to be able to use existing dld-function/.oct
files (e.g. the ones from octave, or any other in the path) without
having to recompile them, basically. And as I was able to use them to
link the compiled program against, I have chosen this option. What would
be the advantages of loading them dynamically instead?

greetings,
Rob Vermaas


Reply | Threaded
Open this post in threaded view
|

Re: Octave compiler

John W. Eaton-6
On  8-Sep-2004, Rob Vermaas <[hidden email]> wrote:

| The issue was that I wanted to be able to use existing dld-function/.oct
| files (e.g. the ones from octave, or any other in the path) without
| having to recompile them, basically. And as I was able to use them to
| link the compiled program against, I have chosen this option. What would
| be the advantages of loading them dynamically instead?

Does it always work on all systems?  For example, can you link
directly to a .oct file on an OS-X or HP/UX system?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave compiler

Per Persson

On Sep 8, 2004, at 17:42, John W. Eaton wrote:

> On  8-Sep-2004, Rob Vermaas <[hidden email]> wrote:
>
> | The issue was that I wanted to be able to use existing
> dld-function/.oct
> | files (e.g. the ones from octave, or any other in the path) without
> | having to recompile them, basically. And as I was able to use them to
> | link the compiled program against, I have chosen this option. What
> would
> | be the advantages of loading them dynamically instead?
>
> Does it always work on all systems?  For example, can you link
> directly to a .oct file on an OS-X or HP/UX system?

Nope, at least on OS X you can't use .oct files as shared libs.

/Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare


Reply | Threaded
Open this post in threaded view
|

Re: Octave compiler

Rob Vermaas
In reply to this post by John W. Eaton-6
Hi,

Sorry for the late response, but I've been quite busy in the meanwhile,
as I found some of your remarks a good excuse to do some cleaning up and
rewriting of the code of the compiler.

>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?
>  
>
You are right that nearly all builtin function work. So mainly builtin
functions that depend on the interpreter related things do not work
completely.

>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.
>  
>
I have followed your advise on writing a tree_walker implementation. It
is nearly finished and works well.

>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?
>  
>
As I changed to using more of the internals of Octave, these lists have
become redundant, therefore it is not necessary for us to generate them.


greetings,
Rob Vermaas


Reply | Threaded
Open this post in threaded view
|

Re: Octave compiler

John W. Eaton-6
On 27-Sep-2004, Rob Vermaas <[hidden email]> wrote:

| I have followed your advise on writing a tree_walker implementation. It
| is nearly finished and works well.

Have you needed to make any changes to the internals of Octave to
support your compiler?  If so, can you please submit the changes along
with explanations about why they are needed?

Thanks,

jwe