Skip site navigation (1) Skip section navigation (2)

Re: solaris build problem with Sun compilers

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: stange(at)rentec(dot)com
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-ports(at)postgresql(dot)org
Subject: Re: solaris build problem with Sun compilers
Date: 2006-05-18 00:07:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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

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

In response to

pgsql-ports by date

Next:From: Theo SchlossnagleDate: 2006-05-18 00:21:32
Subject: Re: solaris build problem with Sun compilers
Previous:From: Bruce MomjianDate: 2006-05-18 00:04:17
Subject: Re: solaris build problem with Sun compilers

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group