Newsgroups: | comp.compilers |
From: | preston@dawn.cs.rice.edu (Preston Briggs) |
Keywords: | registers, optimize, linker |
Organization: | Rice University, Houston |
References: | 92-05-123 92-06-017 |
Date: | Thu, 4 Jun 1992 04:38:00 GMT |
andrew@rentec.com (Andrew Mullhaupt) writes:
>A simple case is that of a multidimensional adaptive integration
>which calls a FORTRAN coded local integration routine. You call the
>local integrator, and then it calls you back many (15 in the case of
>QK15) times. For each of these callbacks you do one FLOP, excluding
>what the function really takes, but it is often enough that the
>integral of small function is complicated enough to pay the freight.
I think you're saying that you pass a function into a routine that calls
the argument function several times and each invocation of the argument
function is very simple, requiring only one Flop. But if it's so simple,
how much register save and restore overhead can there be? Usually a call
to a simple leaf function can be accomplished with very few cycles of
overhead (a call and return, with no registers saved, and no stack frame
allocated).
On the other hand, if the argument function is more complex, the overhead
goes up somewhat, depending on how many registers must be saved. The hope
is that a function requiring 15 or 20 registers will be spending more than
a few cycles doing real work.
>Can an interface spec. _really_ improve compiliation of units which are to
>be dynamically loaded into an alien host program? I can't see this issue
>clearly enough to answer this question.
Interface specifications surely help with interprocedural type checking
and optimization. However, your specification of "dynamically loaded" and
"alien host" make me uncertain. Probably you're wanting to do stuff that
is hairy beyond what I've imagined (like somehow interfacing an APL
interpreter to IMSL subroutines).
Preston Briggs
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.