* [PATCH] MEMORY_BARRIER default [not found] ` <1016742904.5188.166.camel@myware.mynet> @ 2002-03-22 0:28 ` Jakub Jelinek 2002-03-22 0:37 ` Ulrich Drepper 2002-03-25 9:41 ` David Mosberger 0 siblings, 2 replies; 5+ messages in thread From: Jakub Jelinek @ 2002-03-22 0:28 UTC (permalink / raw) To: Ulrich Drepper; +Cc: Mark Brown, Glibc hackers On Thu, Mar 21, 2002 at 12:35:04PM -0800, Ulrich Drepper wrote: > On Thu, 2002-03-21 at 11:46, Jakub Jelinek wrote: > > > Shouldn't sysdeps/ia64/pt-machine.h instead define a > > MEMORY_BARRIER (to something like: > > __asm__ __volatile__("" : : : "memory"); > > )? > > This looks more correct. Though this should probably be the default for > all platforms which don't define specific BARRIER macros. Like this? 2002-03-22 Jakub Jelinek <jakub@redhat.com> * internals.h (MEMORY_BARRIER): Clobber memory if architecture doesn't define its own barrier. * sysdeps/mips/pt-machine.h (MEMORY_BARRIER): Remove. --- libc/linuxthreads/sysdeps/mips/pt-machine.h.jj Fri Mar 22 09:28:10 2002 +++ libc/linuxthreads/sysdeps/mips/pt-machine.h Fri Mar 22 09:28:29 2002 @@ -30,10 +30,6 @@ extern long int testandset (int *spinlock); extern int __compare_and_swap (long int *p, long int oldval, long int newval); -/* Memory barrier. */ -#define MEMORY_BARRIER() __asm__ ("" : : : "memory") - - /* Spinlock implementation; required. */ PT_EI long int --- libc/linuxthreads/internals.h.jj Fri Mar 22 09:19:41 2002 +++ libc/linuxthreads/internals.h Fri Mar 22 09:25:28 2002 @@ -194,11 +194,12 @@ static inline int nonexisting_handle(pth #endif /* If MEMORY_BARRIER isn't defined in pt-machine.h, assume the architecture - doesn't need a memory barrier instruction (e.g. Intel x86). Some + doesn't need a memory barrier instruction (e.g. Intel x86) and just prevent + the compiler from caching memory structures in registers accross it. Some architectures distinguish between full, read and write barriers. */ #ifndef MEMORY_BARRIER -#define MEMORY_BARRIER() +#define MEMORY_BARRIER() __asm__ __volatile__ ("" : : : "memory") #endif #ifndef READ_MEMORY_BARRIER #define READ_MEMORY_BARRIER() MEMORY_BARRIER() Jakub ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MEMORY_BARRIER default 2002-03-22 0:28 ` [PATCH] MEMORY_BARRIER default Jakub Jelinek @ 2002-03-22 0:37 ` Ulrich Drepper 2002-03-25 9:41 ` David Mosberger 1 sibling, 0 replies; 5+ messages in thread From: Ulrich Drepper @ 2002-03-22 0:37 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Mark Brown, Glibc hackers [-- Attachment #1: Type: text/plain, Size: 414 bytes --] On Fri, 2002-03-22 at 00:27, Jakub Jelinek wrote: > Like this? You're a few minutes too late. Well, I haven't added the MIPS stuff yet so you score a point nevertheless. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MEMORY_BARRIER default 2002-03-22 0:28 ` [PATCH] MEMORY_BARRIER default Jakub Jelinek 2002-03-22 0:37 ` Ulrich Drepper @ 2002-03-25 9:41 ` David Mosberger 2002-04-02 14:30 ` Ulrich Drepper 1 sibling, 1 reply; 5+ messages in thread From: David Mosberger @ 2002-03-25 9:41 UTC (permalink / raw) To: Jakub Jelinek; +Cc: hboehm, Ulrich Drepper, Mark Brown, Glibc hackers >>>>> On Fri, 22 Mar 2002 09:27:54 +0100, Jakub Jelinek <jakub@redhat.com> said: Jakub> On Thu, Mar 21, 2002 at 12:35:04PM -0800, Ulrich Drepper Jakub> wrote: >> On Thu, 2002-03-21 at 11:46, Jakub Jelinek wrote: >> >> > Shouldn't sysdeps/ia64/pt-machine.h instead define a > >> MEMORY_BARRIER (to something like: > __asm__ __volatile__("" : : >> : "memory"); > )? >> >> This looks more correct. Though this should probably be the >> default for all platforms which don't define specific BARRIER >> macros. It seems to me that on ia64, MEMORY_BARRIER should expand into: asm volatile ("mf" ::: "memory") or am I missing something? --david ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MEMORY_BARRIER default 2002-03-25 9:41 ` David Mosberger @ 2002-04-02 14:30 ` Ulrich Drepper 2002-04-02 14:40 ` David Mosberger 0 siblings, 1 reply; 5+ messages in thread From: Ulrich Drepper @ 2002-04-02 14:30 UTC (permalink / raw) To: David Mosberger; +Cc: Jakub Jelinek, hboehm, Mark Brown, Glibc hackers [-- Attachment #1: Type: text/plain, Size: 602 bytes --] 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") Yes, and I've added an appropriate change. I'm not entirely clear how the mf.a form comes into play. We have separate READ_MEMORY_BARRIER and WRITE_MEMORY_BARRIER macros and mf.a might fit for one of them. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MEMORY_BARRIER default 2002-04-02 14:30 ` Ulrich Drepper @ 2002-04-02 14:40 ` David Mosberger 0 siblings, 0 replies; 5+ messages in thread From: David Mosberger @ 2002-04-02 14:40 UTC (permalink / raw) To: Ulrich Drepper Cc: David Mosberger, Jakub Jelinek, hboehm, Mark Brown, Glibc hackers >>>>> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-04-02 22:40 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <AE06E1AA-3C4A-11D6-98E8-0030657603C6@us.ibm.com> [not found] ` <20020321204602.X32482@sunsite.ms.mff.cuni.cz> [not found] ` <1016742904.5188.166.camel@myware.mynet> 2002-03-22 0:28 ` [PATCH] MEMORY_BARRIER default Jakub Jelinek 2002-03-22 0:37 ` Ulrich Drepper 2002-03-25 9:41 ` David Mosberger 2002-04-02 14:30 ` Ulrich Drepper 2002-04-02 14:40 ` David Mosberger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).