On May 23, 2006, at 11:21, Jon Smirl wrote:
A new calling convention could push two return addresses for functions
that return their status in EAX. On EAX=0 you take the first return,
EAX != 0 you take the second.
This seems the same as passing an extra function pointer
argument and calling
On 5/25/06, Geert Bosch [EMAIL PROTECTED] wrote:
On May 23, 2006, at 11:21, Jon Smirl wrote:
A new calling convention could push two return addresses for functions
that return their status in EAX. On EAX=0 you take the first return,
EAX != 0 you take the second.
This seems the same as
On 5/25/06, Jon Smirl [EMAIL PROTECTED] wrote:
I ran into another snag that taking the alternative return on a P4 has
really bad performance impacts since it messes up prefetch. This
sequence is the killer.
addl$4, %esp
ret /* Return to
On May 25, 2006, at 13:21, Jon Smirl wrote:
jmp *4($esp)
This is slightly faster than addl, ret.
The point is that this is only executed in the error case.
But my micro scale benchmarks are extremely influenced by changes in
branch prediction. I still wonder how this would
Looking at assembly listings of the Linux kernel I see thousands of
places where function returns are checked to be non-zero to indicate
errors. For example something like this:
mov bx, 0
.L1
call foo
test ax,ax
jnz .Lerror
Another calling convention could be to not only
On May 24, 2006, at 2:54 AM, Etienne Lorrain wrote:
Another calling convention could be to not only return the return
value
in %eax (or %edx:%eax for long long returns) but also its
comparisson to
zero in the flags, so that you get:
call foo
jg .Lwarning
jnz .Lerror
And you
--- Andrew Pinski wrote:
On May 24, 2006, at 2:54 AM, Etienne Lorrain wrote:
Another calling convention could be to not only return the return
value in %eax (or %edx:%eax for long long returns) but also its
comparisson to zero in the flags, so that you get:
call foo
jg
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
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
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
On May 23, 2006, at 8:21 AM, Jon Smirl wrote:
Or am I just reinventing a variation on exception handling?
:-)
* Jon Smirl:
Is the callstack branch correctly predicted if the routine being
called is complex?
At least the AMD CPUs have implemented a special return stack cache,
so the answer is probably yes.
This does eliminate the test./jmp after every function call.
Yes, but the test/jump now
On 5/23/06, Florian Weimer [EMAIL PROTECTED] wrote:
Yes, but the test/jump now happens in the callee, and you need to
maintain an additional stack slot. I wouldn't be surprised if the
The callee already had to implement the test/jmp in order to decide to
return the error. So this shouldn't
On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl 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?
It's fairly close to Fortran alternate
On 5/23/06, Gabriel Paubert [EMAIL PROTECTED] wrote:
On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl 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
15 matches
Mail list logo
