Re: octave and LLVM google summer of code project

[dbateman]

Eugene I wrote:
> 
> For JIT code I would suggest looking under trunk (same path to libMatC) or
> under branches/Freemat4 (which is unstable branch for the next release).
> Both work with llvm version 2.1.
> 
> Array-rework branch is experimental - we are trying to replace internal
> array representation to make arrays easier to use in both interpreter and
> JIT compiler. This branch is work in progress and probably doesn't compile
> yet.
> 

I took the array-rework branch as the JIT in the other branch has been
changed for nearly three months, whereas the array-rework branch there was a
merge dated 9 days ago and so it seemed fresher.. So no work has been done
on the JIT in the last three months or are there newer versions elsewhere?



> In JITFunc.cpp you would see several examples of calling internal FreeMat
> functions. For functions that won't benefit from compiling we just call
> internal FreeMat functions (same ones as interpreter would). Also, we
> weren't brave enough to access C++ objects and functions inside JIT
> compiled code, so we simply create C thunks for that (also in
> JITFunc.cpp).
> 

Yes but the array class is so different from Octave to FreeMat that I expect
that JITFunc is more inspiration that useful code for Octave :-)



> 
> dbateman wrote:
>> 
>> I've always felt that Octave should profit more than it has from the
>> FreeMat code and visa-versa. This looks like a good chance to put that
>> into practice. Ideally we should get you to fix all the bug first ;-)
>> 
> 
> Same goes for the FreeMat team - we'll be glad to share (code, not the
> bugs :). Also, there is a lot of work done by the Octave team implementing
> toolboxes and we wouldn't want to redo this work. 
> 

Yeah I read some of your forum posts, particularly wrt unwind_protect in
Octave. Why not just write a stub function for unwind_protect,
unwind_protect_cleanup and end_unwind_protect that does nothing. The
restoration of the variables won't happen in case of an error, but the code
should work. Otherwise do a replacement like

unwind_protect
<block1>
unwind_protect_cleanup
<block2>
end_unwind_protect

with 

try
<block1>
catch
<block2>
rethrow(lasterror())
end

if you have the rethrow and lasterror functions? This will work for the
error cases, but not for an interrupt which the unwind_protect block also
runs the cleanup code

D.

-- 
View this message in context: 
http://www.nabble.com/octave-and-LLVM-google-summer-of-code-project-tp16565922p16793223.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.