>>>>> "Richard" == Richard Fateman <fateman@cs.berkeley.edu> writes:
Richard> f2cl tries to simulate this by changing call foo(a,b,c)
Richard> to
Richard> (multiple-value-setq (a b c) (foo a b c))
Richard> and having foo return 3 values. This is call by value-return,
Richard> which is ordinarily acceptable as fortran semantics.
f2cl still works this way, except if a is an array, in which case the
modifications to a were already done. Some other minor differences
exist now too.
Richard> But this does not support array slices. e.g. fortran
Richard> dimension a(400)
Richard> ...
Richard> call foo(a(300))
Richard> gives foo access to a 101 element array, a(300) to a(400).
f2cl now supports this, but it needs help because it can't tell from
the call to foo if you wanted the slice or the single element. You
specify :array-slicing T when calling f2cl. In this case, f2cl will
convert a(300) into a displaced array of the appropriate dimensions.
And then you need to compile foo with :array-type :array because the
arrays being passed to foo aren't simple-array's.
Doing so will usually incur a pssibly significant performance penalty
because the arrays are no longer simple-array's.
Fortunately, most Fortran code for special functions don't take array
inputs.
Richard> Linear algebra programs do this frequently, making translation
Richard> of BLAS code via f2cl using this mvsetq trick impossible.
One further complication is that Fortran uses column-major order and
Lisp uses row-major. The current f2cl no longer translates N-dim
arrays into N-dim lisp arrays. All Fortran arrays are converted to
1-D lisp arrays with macros to access the correct element in
column-major order.
I think a BLAS/LAPACK conversion would actually work now but I haven't
tried it. I have used the array slicing feature to get QUADPACK
translated to Lisp. However, I think that's a bad idea. This is a
clear case where FFI is the way to go. But if you can't (like Clisp
on Mac OS X doesn't have FFI at all), then this is an option.
Richard> Fortran arrays have no headers. In fact, fortran memory is a huge
Richard> array, and variables are indexes into it. So the
Richard> resulting lisp code for, say x=y+z officially should
Richard> look like (setf (aref mem x_offset)(float+ (aref mem y_offset)(aref
Richard> mem z_offset)))
Yes. Except "mem" has to be some real Lisp array.
Richard> When the fortran system probably has x,y,z in registers,
Richard> it is a lot faster. If you write the lisp code as (setf x (+ y z))
Richard> it might work but it is not exactly the same.
The one benchmark I ran (TOMS 715) quite a while ago, the Lisp code
was about 25-50% slower, I think. I think the primary reason was the
integer arithmetic because Lisp had to use generic arithmetic just in
case the result was too big. I'm sure f2cl could be made to wrap the
arithmetic with appropriate declarations to just work in native 32-bit
integers and forget about bignums, if this is truly important.
Richard> There may be other screw cases for f2cl other than array slices.
Richard> And f2cl only claimed to be a partial translation.
Richard> Maybe things have changed though and f2cl does more now?
I think f2cl is much more complete than it was. Common blocks are
handled in a better way now, but you still can't have the same common
block with different variables and types in the block. Fortran
PARAMETER statements are handled better. All routines SAVE there
variables which is the de facto standard in Fortran, even though I
think it was unspecified. String operators work better now. Spaces
in numbers are recognized and ignored correctly (a common Fortran
practice). Data statements with or without implied do loops are
handled better, but still need work.
However, equivalence statements definitely don't work. (I have a
solution but that gets deep in the the internals of the Lisp system.)
Fortran I/O still needs major work, but most simple output works, and
Hollerith strings in format statements are recognized. Hollerith
strings in code are broken.
f2cl still has some parser bugs that I've never been able to fix.
Fortunately, every one that I've found either showed up in f2cl
immediately or when compiling the converted Lisp. And the bugs were
easily fixed by adding either a space or an extra set of parentheses
to the Fortran code.
f2cl is very far from perfect but it is usable.
Ray