Compiling 6.4 on NetBSD-current/pc532 - Mailing list pgsql-hackers

From Jon Buller
Subject Compiling 6.4 on NetBSD-current/pc532
Date
Msg-id 199809140016.TAA03084@bullbox.heeia.hi.us
Whole thread Raw
Responses Re: [HACKERS] Compiling 6.4 on NetBSD-current/pc532  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
OK,

I have a current version of PostgreSQL running on my pc532 now.
(It's a NS32K based machine.  Somewhat of an antique really...)

I had to apply the following diffs to get it to compile, but it
then passed the spinlock test, and most of the regression tests,
including the int8 test.  It did not, however, get the datetime
test correct.

For some reason which I haven't figured out yet, it thinks the
following:

template1=> select ('epoch'::datetime) as ZeroSecs;
zerosecs
----------------------------
Fri Dec 31 18:00:00 1999 CST
(1 row)

template1=> select ('current'::datetime) as ZeroSecs;
zerosecs
----------------------------
Fri Dec 31 18:00:00 1999 CST
(1 row)

template1=> select ('now'::datetime) as ZeroSecs;
zerosecs
----------------------------
Sun Sep 13 19:05:43 1998 CDT
(1 row)


So it knows how to get the date and time, but not always...  I'd
think this was machine independent, but then I'd expect a MI problem
like that to get fixed very quickly.  So I don't know if it's a
NetBSD/pc532 problem, a NetBSD problem, or a PostgreSQL problem,
but I suspect the first due to a lack of people screaming.

I did build 6.3.2 with -DDATEDEBUG, but I'm not coherent enough
(yet?) to properly deduce anything yet.  It appeared to all be
correct until it printed the results, implying that libc or a
syscall was returning some funny constant perhaps?

Well, with all those disclaimers, here's the patch.  (Beware, I
think I have it reversed, so you probably want to type patch -r...)


*** /usr/local/pgsql/src/include/storage/s_lock.h    Fri Sep 11 19:00:55 1998
--- s_lock.h    Sat Sep 12 00:27:51 1998
***************
*** 213,219 ****
  #endif     /* NEED_I386_TAS_ASM */


! /* NS32K code is in s_lock.c */

  #endif     /* defined(__GNUC__) */

--- 213,234 ----
  #endif     /* NEED_I386_TAS_ASM */


!
! #if defined(NEED_NS32K_TAS_ASM)
!
! #define S_LOCK(lock)                \
! {                        \
!     slock_t res = 1;                \
!     while (res) {                \
!       __asm__("movqd 0, r0");            \
!       __asm__("sbitd r0, %0" : "=m"(*lock));    \
!       __asm__("sprb us, %0" : "=r" (res));    \
!       res = ((res >> 5) & 1);            \
!     }                        \
! }
!
! #endif     /* NEED_NS32K_TAS_ASM */
!

  #endif     /* defined(__GNUC__) */

*** /usr/local/pgsql/src/backend/storage/buffer/s_lock.c    Thu Sep 10 23:08:00 1998
--- s_lock.c    Sat Sep 12 00:23:04 1998
***************
*** 118,134 ****
  #endif     /* PPC */


- #if defined(__ns32k__)
- int
- tas(volatile slock_t *lock)
- {
-   int res;
-   __asm__("sbitb 0, %0" : "=m"(*lock));
-   __asm__("sprb us, %0" : "=r"(res));
-   res = (res >> 5) & 1;
-   return res;
- }
- #endif

  #else                            /* defined(__GNUC__) */
  /***************************************************************************
--- 118,123 ----


BTW, does the spinlock code need a TAS function so it can spin for
a while and then declare itself stuck, or does a second process/thread
take care of that.  It would be simpler for the NS32K to just make
the whole lock function be 2 lines of inline assembler, but that
would contain an infinite loop if the lock was stuck...

Jon Buller  <jonb@metronet.com>

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: crash on new system views
Next
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: [HACKERS] Serial Data Type