From octave-maintainers-request at bevo dot che dot wisc dot edu Wed Dec 18 16:17:46 2002
Subject: Re: Creating a standalone executable
From: JD Cole <jdcole at san dot rr dot com>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
CC: octave-maintainers at bevo dot che dot wisc dot edu, Randy Gober <GoberR@Bellsouth.net>
Date: Wed, 18 Dec 2002 14:29:17 -0800

Thanks Paul and John,
  That tied some things together for me. And to answer question John, 
yes, I've been doing a little work on a Octave to C++ translator. I 
don't have much to show yet, so I haven't been very vocal about it. As 
Paul and I had previously discussed, I am attempting to use the 
tree_walker interface to emit code (I called it tree_emit_cplusplus). My 
inquiry, and patches, for tree_checker were are related to this effort. 
I would like to run tree_checker prior to emitting code so I don't have 
to worry about bad trees when I go to emit code. For testing right now I 
am implementing tree_emit_cplusplus in an oct-file because  the compile 
overhead is so much less, however, if proven useful, we may want to 
integrate the functionality into Octave itself, similar to the way GNU 
Emacs has a built-in Lisp compiler.

Some of the issues/ideas I have been kicking around:
1. This is a function compiler.
2. I have implemented a function interface, right now the following 
function script:
------------ mysum.m -------------------
function [a,this,b] = mysum (this, that, those)
  a=[1 2 3 4 5];
 
  res= 0;
    
  for i=1:5
    res= res + a(i);
  end
  b
  res
endfunction
----------------------------------------
tranlates to this:
---------------- mysum.cc ----------------
#include <octave/oct.h>

extern void
mysum (octave_value& this, const octave_value& that, const octave_value& 
those,
       octave_value& a, octave_value& b)
{
.......
}
where input only parameters are marked as const and input/output pairs 
are used to alter return values.
3. I am currently educating myself about range values so I can implement 
simple looping.
4. One major sticking point right now is the setting of constant 
vector/matrix values. I noticed that the constructors which use 
pointer-based initialization are private. Still not sure on a "clean" 
method of doing this. I would like to do something like this:
------------
double init_data[10]={1,2,3,4,5,6,7,8,9,0};

octave_matrix m(init_data,2,5);
------------
to try to keep things clean.
5. I'm using a simple hash table to keep track of valid symbol/variable 
names.
6. Perhaps after single functions can be translated, a recursive 
translator can be created which will produce a directory containing all 
the code, .oct and tranlated C++, to created a complete working executable.

JD

John W. Eaton wrote:

>On 18-Dec-2002, Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov> wrote:
>
>| octave_value is part of liboctinterp.  Many of the classes on which the
>| octave_value types are based are defined in liboctave.  E.g., liboctave
>| defines Matrix, which is wrapped by octave_matrix.
>| 
>| octave_value implements dynamic typing, so all operations must be looked
>| up at run time every time they are invoked.  
>| 
>| Things like the * operator for the Matrix class, however, are resolvable
>| at compile time.
>| 
>| Most of the code in e.g., src/DLD-FUNCTIONS, operates directly on values
>| of the underlying type rather than on the octave_value item.
>
>Right.  I'm not sure why you would want to operate directly on
>octave_value objects unless you were working on a simple Octave to C++
>translator or if you are trying to write some generic functions in C++.
>(For example, C++ code that can do the equivalent of something like:
>
>  function result = add (a, b)
>    result = a + b;
>
>and not have to do any type checking/value extraction before
>attempting the addition.)
>
>If you are writing generic functions, why not just write them in the
>scripting language?
>
>If you are working on a translator, then it might be useful to share
>some of your ideas on the list.
>
>Thanks,
>
>jwe
>
>  
>