On May 17, 2006, at 8:30 PM, Bruce Momjian wrote:
> Theo Schlossnagle wrote:
>>> 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.
>
> OK, so what do you suggest? Remove that URL from the comments?
> Anything else?
If you compile with -xarch=v8plus you should be able to omit the
#ifdef's entirely. The sparcv8plus and sparcv9 cas instruction are
identical. Is the goal here to support Sparc chips that do not
support the v8plus instruction set? I'm not on the ports list, so
maybe I missed the original problem report.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: Run with it.
