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

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