On 5/23/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> Has work been done to evaluate a calling convention that takes error
> checks like this into account? Are there size/performance wins? Or am
> I just reinventing a variation on exception handling?
This introduces an extra stack push and will confuse a call-stack branch
predictor. If both the call stack and the test are normally predicted
correctly I'd guess this would be a performance loss on modern cpus.
Note that the error return is above the normal return and not placed
there by a call, it should look like data to the predictor. The normal
return is placed on the stack by a call which should continue to be
correctly predicted, I would expect the error return path to be
mispredicted but it is supposed to be the unlikely case. Is the
callstack branch correctly predicted if the routine being called is
complex?
This does eliminate the test./jmp after every function call.
Further branches could be eliminated by having multiple returns from
the called function at the expense of increasing code size.
Paul
--
Jon Smirl
[EMAIL PROTECTED]
