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

cdg@nullstone.com (Christopher Glaeser)
21 Jun 1996 17:20:33 -0400

          From comp.compilers

Related articles
[23 earlier articles]
Re: Java virtual machine as target language for C/C++ wws@renaissance.cray.com (1996-05-25)
Re: Java virtual machine as target language for C/C++ tmb@best.com (1996-05-26)
Re: Java virtual machine as target language for C/C++ dw3u+@andrew.cmu.edu (Daniel C. Wang) (1996-05-27)
Re: Java virtual machine as target language for C/C++ dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-06-08)
Re: Java virtual machine as target language for C/C++ d.love@daresbury.ac.uk (Dave Love) (1996-06-13)
Re: Java virtual machine as target language for C/C++ bos@serpentine.com (1996-06-14)
Re: Java virtual machine as target language for C/C++ cdg@nullstone.com (1996-06-21)
compilation to C [was Re: Java virtual machine...] d.love@daresbury.ac.uk (Dave Love) (1996-06-23)
Optimization of Uncommon Code (Was Java ByteCode ...) dlmoore@ix.netcom.com (1996-06-30)
Re: Optimization of Uncommon Code (Was Java ByteCode ...) wws@renaissance.cray.com (Walter Spector) (1996-07-01)
Re: Optimization of Uncommon Code dwight@pentasoft.com (Dwight VandenBerghe) (1996-07-02)
Re: Optimization of Uncommon Code (Was Java ByteCode ...) ok@cs.rmit.edu.au (1996-07-04)
Re: Optimization of Uncommon Code (Was Java ByteCode ...) grout@polestar.csrd.uiuc.edu (1996-07-05)
| List of all articles for this month |

From: cdg@nullstone.com (Christopher Glaeser)
Newsgroups: comp.compilers
Date: 21 Jun 1996 17:20:33 -0400
Organization: Compilers Central
References: 96-05-061 96-05-163 96-06-048
Keywords: UNCOL, C, Fortran

> 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
--


Post a followup to this message

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