On May 17, 2006, at 8:04 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Tom Lane wrote:
>>> Alan Stange <stange@rentec.com> writes:
>>>> I believe the trick here is that Solaris 10 will only run on v9
>>>> hardware
>>>> (or the sun4u systems), which all have the instruction. But
>>>> the v8 ABI
>>>> "model" doesn't have it. So, in some sense the ABI doesn't
>>>> "allow"
>>>> this instruction, but the hardware does, so they can just slam
>>>> it in
>>>> knowing that it'll work.
>>>
>>> Well, that might be OK for Sun's compiler since they know what a
>>> given
>>> version of Solaris will run on. But I don't think we can adopt
>>> the same
>>> attitude for our gcc code path; that has to work on Sparc-based
>>> Linuxen
>>> and BSDen. I don't think it's appropriate to kiss off support
>>> for v8
>>> chips when we haven't seen any proof at all of a performance
>>> boost in
>>> return.
>>>
>>> Maybe the right answer is to leave the code as-is, ie,
>>> deliberately not
>>> the same for Sun and gcc compilers.
>>
>> OK, I have applied the following patch which documents that the
>> Solaris
>> CC TAS ASM only works for sparc9. Hopefully either sparc8 is not
>> needed
>> (unlikely) or someone will fix it. I have CC'ed the original
>> contributor who added "cas".
>
> Oh, I just found this email that has a simplified sparc8 asm:
>
> http://archives.postgresql.org/pgsql-ports/2006-05/msg00025.php
>
> Attached is the new solaris_sparc.s file with the #ifdef sparc8 test;
> applied.
I don't think that asm does what you think it does. That hex
encoding of the cas instruction doesn't work on Sparcv8, only
sparcv8plus. The reason that it is hacked that way is that, for
other reasons, they can't use the -xarch=v8plus flag (despite
compiling on v8plus capable chips). Basically that code hardcodes a
v8plus instruction into a v8 binary "knowing" that it will never run
on a non-v8plus capable chip. The reason that they can do this is
because they (as I understand it) open solaris won't support any
chips so old as to not run v8plus code.
We shouldn't be suffering from that problem and -xarch=v8plus should
be used to produce 32-bit binaries and -xarch=v9 should be used to
produce 64-bit sparc binaries. I can't think of a reason to every
compile the Postgres source with -xarch=v8 instead of -xarch=v8plus,
the latter will produce much better code overall.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: Run with it.
