Date: Sat, 16 Dec 2000 09:29:54 -0700 From: Chuck Paterson <cp@bsdi.com> To: Bruce Evans <bde@zeta.org.au> Cc: Julian Elischer <julian@elischer.org>, John Baldwin <jhb@FreeBSD.ORG>, Alfred Perlstein <bright@wintelcom.net>, smp@FreeBSD.ORG Subject: Re: atomic increment? Message-ID: <200012161629.eBGGTsP05883@berserker.bsdi.com> In-Reply-To: Your message of "Sat, 16 Dec 2000 23:59:28 %2B1100." <Pine.BSF.4.21.0012162337350.7092-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually performaning the volatile function ->>may<<- have reduced
register pressure resulting in gcc using the load eax. There sure
isn't much which gcc is going to believe is save to leave in a register
across this instruction sequence once it is tagged as volatile.
This does bring up the point that not all use of atomic ops are
equal. There are those which must not only have the locked prefix
to make the operation work but must be executed in the correct place in
the instruction stream to get correct overall semantics. On the other
hand there are those, such a stat counters, which only need the
lock prefix. These uses really shouldn't require being tagged as volatile.
Chuck
Bruce Evans wrote on: Sat, 16 Dec 2000 23:59:28 +1100
}The movl is a gcc pessimization. gcc should generate:
}
} lock
} addl $1,4(%ebx)
}
}gcc did generate this for old versions of the atomic functions (it
}only started pessimizing this when we added some `volatile' qualifiers).
}
}The above (addl $1...) has exactly the same overheads as:
}
} lock
} incl 4(%ebx)
}
}except it is 1 byte longer so it may take longer to fetch (but
}instruction fetching hasn't been a significant bottleneck since the
}original 386, and I think the instruction fetcher will have even more
}time to keep up than usual because the lock instruction slows things
}down).
}
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012161629.eBGGTsP05883>