Re: [PORTS] solaris build problem with Sun compilers
Alan Stange <[email protected]> Fri, 12 May 2006 16:38:26 -0400
| Newsgroups | gmane.comp.db.postgresql.ports |
|---|---|
| Organization | Renaissance Technologies Corp. |
| Message-ID | <[email protected]> |
Tom Lane wrote: > Alan Stange <[email protected]> writes: >> - postgresql HEAD when using the Solaris compilers spro9 or newer will >> only run on v9 based hardware using v8plus or v9 platform. >> - postgresql HEAD when using gcc will run on anything as they generate >> code for the v7 platform by default and the cas instruction isn't used >> in any assembler code in postgresql. > > I gather from the contents of solaris_sparc.s that the Sun compilers can > be expected to define __sparcv9 if compiling for v9 hardware. I'm > inclined to #ifdef things so that we use cas if that symbol's defined and > ldstub if not. I'm not sure if gcc can be expected to define the same > symbol --- we might end up using ldstub always, even if we try to > conditionalize the code for gcc. This code isn't used by gcc, is it? Or are you thinking to use the same assembler segment in the inline function used by gcc? > Or we could just revert to ldstub. This seems like a lot of complexity > for a so-far-entirely-hypothetical performance gain ... I suspect that on machines like the UltraSparc T1 (the multi-core boxes) this can have an impact (lots of additional memory writes). Even so, that seems like a stretch. Was there any reason given for the cas patch? I might get around to doing the work for the Solaris compiler build to support the inline keyword as well. I hacked on it a bit today but had to get back to real work... -- Alan ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [email protected] so that your message can get through to the mailing list cleanly