Re: write statement output buffer flush off on Sun

From: James Van Buskirk (not_valid_at_comcast.net)
Date: 03/30/04 

Date: Tue, 30 Mar 2004 20:17:48 GMT

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:e3kac.2743$He5.65439@bgtnsc04-news.ops.worldnet.att.net...

> All this is irrelevant in the case where the alternate return is done
> in the callee. In that case, the usual return has not alternatives to
> select from at all. It looks just like a normal return. There are
> no tests or other conditional activities in either the caller or the
> callee that need to be done in any order or that need to rely on
> any form of branch prediction, speculative execution, or anything
> else. The normal return is a normal return.

> In the case of the exceptional return being taken, the callee rolls
> up the stack properly and returns to the caller directly at the
> alternate point. Again, no speculation, conditional choices,
> or anything else. The return look just like a normal return
> except that the return address is different. All the choices have
> already been made inside the procedure when it chooses what
> RETURN statement to execute. And that's done with the normal
> conditional statements of the language (IFs, CASEs, etc.).

I think I can see what you're talking about here, although it
took a couple of readings. If the alternate return is infrequent
it would have been mispredicted every time if it were an infrequent
branch of an IF or SELECT CASE, so it wouldn't lead to performance
loss relative to a caller-implemented mechanism.

The only instance where performance loss would occur would then
be if one of the alternate returns were the rule rather than the
exception in which case only a processor that didn't maintain
a return stack (like a Pentium Classic) would start predicting
the right branch while a more contemporary processor (like a
Pentium MMX, even) that uses a hardware return stack for branch
prediction would mispredict every time the alternate returns if
implemented by the mechanism you suggest because the return
address would never match the address pushed on the (programmer-
invisible) return stack. 

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Relevant Pages

  • Re: calling convention
    ... caller and callee communicate, be it via the stack or registers. ... without consideration of calling convention.. ...
    (microsoft.public.vc.language)
  • Re: [OT] [Question]activities of stack pointer and frame pointer when function called
    ... >>I suspect you don't understand what as stack frame is. ... A function stack frame is a method to keep track of function ... At the point of creation the caller is ... When the callee returns to its ...
    (comp.lang.c)
  • Re: write statement output buffer flush off on Sun
    ... the test of the return-code in the caller after every ... The callee, when using alternate return, must select the alternate ... incorrectly predicted ones - in fact, why have branch prediction logic ... Almost all modern processors will have a special form of branch ...
    (comp.lang.fortran)
  • Re: write statement output buffer flush off on Sun
    ... (previously snipped discussion about doing Fortran alternate ... return logic in the caller or callee.) ... >> the caller on some hardware can be a large win (especially if the ... > prediction, often in the form of a so-called return stack. ...
    (comp.lang.fortran)
  • Re: Passing parameter to function not expecting parameter
    ... some data hanging around on a stack or something that could get future ... caller and callee, each side bearing part of the responsibility. ... If the caller says "I'm pushing two arguments and I know the called ...
    (comp.lang.c)