Re: Octave Compiler

[JD Cole]

Jens Ruecknagel wrote:

> Hi again JD Cole,

Please call me JD.

> after a lot of thinking I've concluded, that I want to build the 
> compiler as an .oct file - but it should produce stand alone code 
> (maybe based on liboctave) - but I have to check with my Professor, 
> and I just cannot get in touch with him.

Probably the best choice, initially. This will be much more straight 
forward than developing your own code to deal with all of Octave's 
dynamic allocation, to say the least.

> So right now I am looking at your code. And now I have many Questions:
>
> What is the file goal.cc for?
> Is it just, what you wish compile to produce?

Yes, I believe that what it was.

> What does the operator |= in compile.cc do?

> Is it bitwise OR and assign? Or is it logical OR and assign (sorry 
> about the C++ stuff, but obviously you thought about it)

I wouldn't go so far as to say I thought about it, but I have attached a 
version of compile.cc with more comments, sorry, at the time I wasn't 
thinking this code would get outside of my little sandbox.

> More Questions as son as I ran into them and cannot figure it out.

Something else that will end up being a big issues when you go to 
implement the converter is how you are going to deal with references 
external to the function your converting. Theses will include both .m 
and .oct files.

1) Since .oct files are already in a useable state, as far as C++ is 
concerned, you could possibly link your code with them (although I'm not 
sure if code compiled as a shared object can later be linked into a  
single binary. So you could:
   a) A just have the compiler generate a list of modules it will be 
dependent on in order to execute, and then copy or require those modules 
to be copied into the same directory as the executable. (This would, of 
course require you to familiarize yourself with loading shared 
object...luckily Octaves designers have a nice C++ interface for shared 
object loading.)
   b) Recompile those modules into your code, somewhat like octave does 
with built in functions...
   c) There's always a "c", but I'm not sure what it is.
   d) Don't allow compiled functions to contain external 
references....with the exeception of builtins, which I think are in one 
of the octave libraries. (This may be the best idea as a first attempt 
at code conversion...it's not as glorious, but definitely has value.)
   e).....

2) .m files are another issues, which could end up being somewhat 
recursive should you decide to compile the .m's external to your code. 
I'm talking about when you determine that the external function is a .m 
not a .oct file, you choose to compile it into your code also.

Anyways, more to think about. Anyone have any comments on this?

JD