Re: [HACKERS] Compiling 6.4 on NetBSD-current/pc532

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: jonb(at)metronet(dot)com (Jon Buller)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Compiling 6.4 on NetBSD-current/pc532
Date: 1998-09-18 05:32:06
Message-ID: 199809180532.BAA24646@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)metronet(dot)com>
>
>

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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. |

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Gould 1998-09-18 06:27:48 Re: [HACKERS] Compiling 6.4 on NetBSD-current/pc532
Previous Message Bruce Momjian 1998-09-18 05:14:45 Re: [HACKERS] pg_user backtrace -- with ElectricFence (looks useful :)