On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote:
> On 01/07/14 11:04, Andres Freund wrote:
>
> >>Since we have a Sun Studio machine in the buildfarm, we shouldn't give
> >>up on SPARC completely, but maybe we should only add the cases for
> >>sparcv8+ and above? That at least has some chance of getting tested.
> >
> >That we have code for sparcv7 is ridiculous btw. Sparcv8 (not 8+/9) is
> >from 1992. v7/sun4c been dropped from solaris 8 if I see that correctly.
> >
> >I agree that v8 (in contrast to v8+ aka v9 in 32bit mode) support has to
> >go as well. I'd personally vote for backpatching a note to
> >installation.sgml saying that it's probably not working, and not do
> >anything else there. That means we also should replace the ldstub by cas
> >in the the gcc inline assembly - but we have buildfarm members for that,
> >so it's not too bad.
>
> Being involved in QEMU SPARC development, I can tell you that patches are
> still actively being received for SPARCv8. The last set of CPU patches were
> related to fixing bugs in the LEON3, a 32-bit SPARC CPU which is available
> in hardened versions certified for extreme environments such as military and
> space. I'd hate to find out that they switched to another database because
> they couldn't upgrade PostgreSQL on the ISS ;)
LEON3 isn't really sparcv8. It's more like sparcv8 with v9 stuff cherry
picked... It e.g. has CAS :)
Your point stands though - we should probably backpatch the v8 version
of my patch as well, since apparently LEON3 does *not* have membar.
But I don't think this is a rat race we can win. We can't keep up with
all the variants of sparc and even worse arm. We should add a intrinsics
based version for sparc as well. That'll work just fine on any recent
gcc.
> Also if you're struggling for Sun buildfarm animals, recent versions of QEMU
> will quite happily install and run later versions of 32-bit Solaris over
> serial, and 2.0 even manages to give you a cgthree framebuffer for the full
> experience.
Well. I have to admit I'm really not interested in investing that much
time in something I've no stake in. If postgres developers have to put
emulated machines to develop features something imo went seriously
wrong. That's more effort than at least I'm willing to spend.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services