Re: Java virtual machine as target language for C/C++

> Also, my experience of f2c with gcc is that it hasn't been
> substantially slower than the vendor compiler on the platforms I've
> used (specifically MIPS), though I doubt that's true generally.


f2c is a good case study for illustrating one type of problem with language A
to language B translation systems.


One of the problems with f2c/C performance is that f2c converts some contructs
that are common in FORTRAN to constructs that are relatively uncommon in C.
Since compiler developers tend to focus on optimizing common constructs,
the code generated for f2c translations can be less than is technically
possible.


Consider the following example:


SUBROUTINE F(A)
INTEGER A(100)
INTEGER I
DO 10 I = 1, 100
A(I) = 0
10 CONTINUE
END


The output of f2c is:


int f_(a)
integer *a;
{
static integer i;


--a;


for (i = 1; i <= 100; ++i) {
a[i] = 0;
}
}


Note that the loop control variable is declared "static integer" (where
"integer" is generally a typedef for "long int").


The assembly code for the loop generated by the SPARC "gcc -O2" compiler is:


L5:
ld [%o1+%lo(_i.2)],%g3
sll %g3,2,%g2
st %g0,[%o0+%g2]
add %g3,1,%g3
cmp %g3,100
ble L5
st %g3,[%o1+%lo(_i.2)]


Note that the static storage class for the loop control variable i generates
an extra load and store for each iteration.


If the f2c output is hand-optimized by removing the "static" storage class,
the same gcc compiler generates:


L7:
add %g2,4,%g2
cmp %g2,400
ble,a L7
st %g0,[%g2+%o0]


Although it is possible for C compilers to perform this optimization directly,
few C compilers can generate efficient code for this relatively common FORTRAN
construct via f2c.


Given that C compilers generally do not generate efficient code for static
variables, the pragmatic solution to increasing performance is to enhance f2c
so that it avoids static when possible, or at least for the common cases.


Applying this solution to Language X to Java virtual machine translation is
made more difficult by Java's newness and fast pace, since it is difficult to
predict what constructs will perform well using Java tools that are still
being developed.


Best regards,
Christopher Glaeser cdg@nullstone.com
Nullstone Corporation http://www.nullstone.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.