Re: Alpha tas() patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Alpha tas() patch
Date
Msg-id 6054.978039236@sss.pgh.pa.us
Whole thread Raw
In response to Re: Alpha tas() patch  (Brent Verner <brent@rcfile.org>)
List pgsql-hackers
Brent Verner <brent@rcfile.org> writes:
> what have I stumbled into :).  'damnit Jim!, I'm just a perl hacker.'

I've found an online version of the AXP Architecture Handbook at 
ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/index.html
in particular the file ec-qd2ka-te.ps.gz listed near the top of
the page.  After perusing same, it seems that the tas() code presently
in CVS sources *is correct*, although not very transparently written
(for example, "or  $31, 1, $0" would be more clearly expressed as
"mov 1, $0").  See sections 4.2.4, 4.2.5, 4.11.4, and 5.5, especially
the sample code for a software critical section in 5.5.3.

At this point my opinion is that there's nothing functionally wrong
with the existing Alpha assembly code in s_lock.h, and that the
CreateCheckPoint failure is due to CreateCheckPoint misusing the routine
(see my recent message to pghackers).

I believe that we should change s_lock.h to use the inline assembly code
when using gcc on Alpha, regardless of OS.

The more interesting question is what to do for non-gcc compilers.
The INTERLOCKED_TESTBITSS_QUAD macro is not really suitable, primarily
because it does not include an "mb" instruction.  (It also violates the
architecture manual's recommendation to not do redundant stores into a
lock word, but that's not so critical.)  Is there anything in
<alpha/builtins.h> that provides access to the memory-barrier
instruction?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Brent Verner
Date:
Subject: Re: Alpha tas() patch
Next
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: Assuming that TAS() will succeed the first time is verboten