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

At the request of our lock guy, I have had to reverse out this patch.
He wants the locking to follow the current locking code in 6.4.

Hope you will be able to make that change and resubmit.

Thanks.

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


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