At 05:55 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > >Non-inline functions have their place in reducing code size
> > > > >and easing debugging. I just want an i_foo for every foo that callers
> > > > >will have the option of using.
> > > >
> > > > Before we make any promises to do all that extra work can we
> > > > measure (for various architectures) the cost of a real call vs inline.
> > > >
> > > > I want proof that inline makes X% difference.
> > >
> > >I'm not going to prove that. A normal C function call involves
> > >several instructions and a jump most likely across page boundaries.
> >
> > But if that function is already in cache from another use, you win.
> >
> > Assume, for a minute, you've got a 700MHz system with a 100MHz 128-bit
> data
> > bus. If your code is inlined and works out to 256 bytes, that's 16 fetches
> > on the main bus. That costs 112 cycles. On the other hand, if your
>
>Dan, you are completely missing my point. Okay, fine, non-inline may
>be a performance win in some cases. Inline may be a win in others. I
>am not proposing we mandate inlining in any case, I am proposing the
>exact opposite: that we let the caller decide in every case.
Having thought about it a bunch more (because of this) I'm proposing we let
the compiler decide. The caller doesn't know enough to make that decision.
*Especially* if (when) we allow for on-the-fly changing of variable access
subsystems.
We'll be marking a *lot* of functions as inline, and they'll likely get
used often and frequently. (If all the SV, HV, and AV macros become
functions, which they should, it'll be used a lot)
If we go the PI route, the generated files should either have inlined
functions or calls to plain functions, and the PI code generator can work
that out.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
