Compiling 6.4 on NetBSD-current/pc532

Поиск
Список
Период
Сортировка
От Jon Buller
Тема Compiling 6.4 on NetBSD-current/pc532
Дата
Msg-id 199809140016.TAA03084@bullbox.heeia.hi.us
обсуждение исходный текст
Ответы Re: [HACKERS] Compiling 6.4 on NetBSD-current/pc532  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: crash on new system views
Следующее
От: darcy@druid.net (D'Arcy J.M. Cain)
Дата:
Сообщение: Re: [HACKERS] Serial Data Type