Re: Spinlocks and compiler/memory barriers
От | Mark Cave-Ayland |
---|---|
Тема | Re: Spinlocks and compiler/memory barriers |
Дата | |
Msg-id | 53B33453.4090001@ilande.co.uk обсуждение исходный текст |
Ответ на | Re: Spinlocks and compiler/memory barriers (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Spinlocks and compiler/memory barriers
|
Список | pgsql-hackers |
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 ;) 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. ATB, Mark.
В списке pgsql-hackers по дате отправления: