Re: solaris build problem with Sun compilers - Mailing list pgsql-ports

From Bruce Momjian
Subject Re: solaris build problem with Sun compilers
Date
Msg-id 200605180007.k4I073k09866@candle.pha.pa.us
Whole thread Raw
In response to Re: solaris build problem with Sun compilers  (Alan Stange <stange@rentec.com>)
List pgsql-ports
Alan Stange wrote:
> Hello,
>
> I removed the whole tas_dummy() block for sparc from s_lock.c.  I
> recompiled and installed with and without --enable-debug.   I then ran
> pgbench on the box.  This is using the Sun 11 compilers on Solaris 10.
>
> I tested using pgbench
>
> $ pgbench -i -s 32 pgbench
> $ pgbench -s 32 -c 1 -t 10000 -v
>
> for up to 8 clients on an 8 core UltraSparc IV+ system.
>
> Everything compiled and ran fine.
>
>
>
>
> I took a look at backend/port/tas/solaris_sparc.s file.  Isn't that code
> a bit longer than needed?
>
> Aren't the callers of this doing
> while (tas(lock)) {
>    // wait a bit without smashing the kernel/memory bus
> }
>
> in which case the code should just be
>
>     ldstub [%o0],%o0
>     retl
>     nop
>
> without the extra comparisons and branching.  Unless I'm missing something.

Basically the original 8.1 ASM code was placing its own address into the
shared memory address:

    ldstub [%o0],%o0

and then based on what it got back, it was returning 1/0.  The new code
in CVS HEAD places '1' in, so there is no longer a need for the tests.

--
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-ports by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: solaris build problem with Sun compilers
Next
From: Bruce Momjian
Date:
Subject: Re: solaris build problem with Sun compilers