This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> On 02 Apr 2002 14:30:00 -0800, Ulrich Drepper <drepper@redhat.com> said: Uli> On Mon, 2002-03-25 at 09:41, David Mosberger wrote: >> It seems to me that on ia64, MEMORY_BARRIER should expand into: >> >> asm volatile ("mf" ::: "memory") Uli> Yes, and I've added an appropriate change. I'm not entirely Uli> clear how the mf.a form comes into play. We have separate Uli> READ_MEMORY_BARRIER and WRITE_MEMORY_BARRIER macros and mf.a Uli> might fit for one of them. Oh, no, that's not the intended use of mf.a. It's basically intended for implemented IN/OUT instruction emulation. It forces "device acceptance", which adds an off-chip roundtrip. Very bad for performance. In contrast, mf is fairly light-weight (doesn't cause any pipeline disruption; just forces ordering). It would be nice to have a way to take advantage of ia64's acquire/release model, since there are cases where this is much closer to what an application really wants. Hans and I briefly discussed this, but neither of us has had the time to really pursue this. --david
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |