Re: [HACKERS] Compiling 6.4 on NetBSD-current/pc532 - Mailing list pgsql-hackers

Applied.

> 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>
>
>


--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle              |  (610) 353-9879(w)
  +  If your life is a hard drive,     |  (610) 853-3000(h)
  +  Christ can be your backup.        |