Re: removing old ports and architectures - Mailing list pgsql-hackers

On 2013-10-16 16:10:18 -0400, Robert Haas wrote:
> On the other hand, I'm not convinced that we don't need to give any
> thought to UNIX vendors that are still pushing their proprietary
> compilers.  Many of the old players are dead, but IBM's ICC and HP's
> aCC definitely aren't, and I wouldn't be surprised to find one or two
> other big ones as well, plus maybe half-a-dozen others that are
> clinging to life.

acc provides intrinsics for IA64, so that's easily supported. For IBM,
do you mean XLC? If so, that provides intrinsics as well. So does sun
studio.
ICC as in Intel's compiler provides intrinsics as well. In fact, that's
where gcc cribbed most of it's API from.

> > Which? We only seem to disagree about M32R and m68k, right? I've
> > recanted mips and superh days ago ;).
> > If you find alpha important, that's fine, that's supported by gcc. I
> > just doubt we'll get it even remotely right without tests...
> 
> As far as spinlock support goes, you proposed removing VAX, univel,
> sinix, sun3, natsemi 32k, superH, ALPHA, m86k, M32R, mips non-GCC,
> s390 non-GCC, and 32bit/<v9 sparc.  I agreed unequivocally with 4 of
> those (though I don't see the code you're talking about wrt/32bit<v9
> sparc), and you withdrew 2 of those suggestions, so I think there are
> 6 that are still in doubt: vax, univel, ALPHA, m32r, m68k, and s390
> non-GCC.

Well, you didn't sound like you deemed vax and alpha to be that
important and I was only talking about architectures, not OSs...

But anyway hardware architecture wise, all but m32r, m68k and pa-risc
have the required hardware support for atomic add and cmpxchg.

univel/unixware: Supports only x86 (these days at least), so writing the
required assembly is trivial if it comes to that. Testing on the other hand...

s390, s390x: We only support linux anyway, so I don't see the
restriction to gcc being problematic.

alpha: We use gcc inline assembly currently, so it's only gcc again. It
is supported by gcc's intrinsics. We can easily support it if we trust
ourselves to understand the cache coherency.

mips: Besides gcc we only support IRIX, since you voted to remove that,
the restriction to gcc doesn't cost anything.

m68k: Only coldfire chips don't have working CAS. All support atomic add.
m32r: Doesn't have CAS, doesn't support atomic add.
pa-risc: Doesn't have CAS, doesn't support atomic add.


> I do understand that it's going to be painful to carry multiple
> implementations of some of these facilities.  But at least from where
> I sit I'm not sure we really have a choice.  If we have a
> --disable-atomics option, there's no reason we can't have regular
> buildfarm coverage of that code; broken lwlocks tend to make things
> die pretty horribly, so I'm relatively confident bugs will show up.

I am pretty sure lots of that code will only be noticeably under
noticeable concurrency. And we don't exercise that all that much in the
regression tets.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services