On Thu, Jul 7, 2022 at 1:02 AM Peter Eisentraut
<peter.eisentr...@enterprisedb.com> wrote:
> On 06.07.22 04:21, Thomas Munro wrote:
> > /*
> > * Do not try to collapse these into one "w+" mode file. Doesn't work
> > on
> > - * some platforms (eg, HPUX 10.20).
> > + * some platforms.
> > */
> > termin = fopen("/dev/tty", "r");
> > termout = fopen("/dev/tty", "w");
>
> I don't know how /dev/tty behaves in detail under stdio. I think
> removing this part of the comment might leave the impression that
> attempting to use "w+" will never work, whereas the existing comment
> appears to indicate that it was only very old platforms that had the
> issue. If we don't have an immediate answer to that, I'd leave the
> comment as is.
Thanks. I put that bit back, removed the stray mention of "itanium"
in Windows-specific stuff that Andres mentioned, and pushed these
patches.
While adjusting the docs, I noticed a few little inconsistencies here
and there for other ISAs.
* The documented list of ISAs should by now mention RISC-V. I'm sure
it needs some fine tuning but it's working fine and tested by the
build farm.
* The documented list mentions some in different endiannesses and word
sizes explicitly but not others; I think it'd be tidier to list the
main architecture names and then tack on a "big and little endian, 32
and 64 bit" sentence.
* Under "code exists, not tested" we mentioned M68K, M32R, VAX, but
M88K and SuperH are also in that category and have been added/tweaked
in the past decade with reports that imply that they were working on
retro-gear. AFAIK only SuperH-family stuff is still produced. I
don't know much about that and I'm not planning to change anything,
except one special mention...
* Since Greg Stark's magnificent Vax talk[1], we became even more
dependent on IEEE 754 via the Ryu algorithm. AFAICT, unless someone
produces a software IEEE math implementation for GCC/VAX... if I had
a pick one to bump off that list, that's the easiest to argue because
it definitely doesn't work.
* When we removed Alpha we left a couple of traces.
What do you think about the attached?
[1] https://archive.fosdem.org/2016/schedule/event/postgresql_on_vax/
From 3f8dc52fdec8a9a09017d9542d84d78715ec0223 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.mu...@gmail.com>
Date: Fri, 8 Jul 2022 10:19:32 +1200
Subject: [PATCH] Tidy up claimed supported CPUs.
* Be more consistent about listing endianness and bitness variants.
* Mentioned RISC-V.
* SuperH and M88K might as well be mentioned, if M68K is.
* VAX definitely doesn't work anymore, so remove it from docs and code.
* Remaining traces of Alpha support can also be removed from code.
---
contrib/pgcrypto/crypt-blowfish.c | 2 +-
doc/src/sgml/installation.sgml | 7 ++++---
src/include/storage/s_lock.h | 30 ------------------------------
3 files changed, 5 insertions(+), 34 deletions(-)
diff --git a/contrib/pgcrypto/crypt-blowfish.c b/contrib/pgcrypto/crypt-blowfish.c
index a663852ccf..1264eccb3f 100644
--- a/contrib/pgcrypto/crypt-blowfish.c
+++ b/contrib/pgcrypto/crypt-blowfish.c
@@ -41,7 +41,7 @@
#ifdef __i386__
#define BF_ASM 0 /* 1 */
#define BF_SCALE 1
-#elif defined(__x86_64__) || defined(__alpha__) || defined(__hppa__)
+#elif defined(__x86_64__) || defined(__hppa__)
#define BF_ASM 0
#define BF_SCALE 1
#else
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 1a1343a008..eff180b216 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -2125,9 +2125,10 @@ export MANPATH
<para>
In general, <productname>PostgreSQL</productname> can be expected to work on
- these CPU architectures: x86, x86_64, PowerPC,
- PowerPC 64, S/390, S/390x, Sparc, Sparc 64, ARM, MIPS, MIPSEL,
- and PA-RISC. Code support exists for M68K, M32R, and VAX, but these
+ these CPU architectures: x86, PowerPC, S/390, Sparc, ARM, MIPS, RISC-V,
+ and PA-RISC.
+ Big-endian, little-endian, 32-bit and 64-bit systems are supported.
+ Code support exists for M68K, M88K, M32R, and SuperH, but these
architectures are not known to have been tested recently. It is often
possible to build on an unsupported CPU type by configuring with
<option>--disable-spinlocks</option>, but performance will be poor.
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index c4a19b2f43..1f5394ef7f 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
@@ -548,36 +548,6 @@ tas(volatile slock_t *lock)
#endif /* __m88k__ */
-/*
- * VAXen -- even multiprocessor ones
- * (thanks to Tom Ivar Helbekkmo)
- */
-#if defined(__vax__)
-#define HAS_TEST_AND_SET
-
-typedef unsigned char slock_t;
-
-#define TAS(lock) tas(lock)
-
-static __inline__ int
-tas(volatile slock_t *lock)
-{
- register int _res;
-
- __asm__ __volatile__(
- " movl $1, %0 \n"
- " bbssi $0, (%2), 1f \n"
- " clrl %0 \n"
- "1: \n"
-: "=&r"(_res), "+m"(*lock)
-: "r"(lock)
-: "memory");
- return _res;
-}
-
-#endif /* __vax__ */
-
-
#if defined(__mips__) && !defined(__sgi) /* non-SGI MIPS */
#define HAS_TEST_AND_SET
--
2.30.2
