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 perfor
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 err
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 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 t
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 co
--- 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
> >
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
> 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 no
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 exce
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 r
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 i
* 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 ha
On May 23, 2006, at 8:21 AM, Jon Smirl wrote:
Or am I just reinventing a variation on exception handling?
:-)
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 co
> 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 ca
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
inc bx
cmp bx, 10
jne .L1
.Lerror
proc
16 matches
Mail list logo
