Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

On Tue, 11 Apr 2000, Kevin P. Neal wrote:

Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
release 1.4.1.

*** ./old/src/include/storage/s_lock.h  Wed Jan 26 00:58:33 2000
--- ./new/src/include/storage/s_lock.h  Sun Apr  9 23:56:46 2000
***************
*** 260,270 ****
--- 260,275 ----
  #else /* i.e. not __osf__ */

#define TAS(lock) tas(lock)
#define S_UNLOCK(lock) { __asm__("mb"); *(lock) = 0; }

+ #if defined(__GNUC__)
+ static int              /* GCC on the Alpha doesn't appear to handle
+                            inlining of assembly with %0 or %1 properly.
*/
+ #else
  static __inline__ int
+ #endif
  tas(volatile slock_t *lock)
  {
   register slock_t _res;

__asm__(" ldq $0, %0 \n\

Any chance you could write a configure test that exposes this deficiency
rather than assuming that every GCC on every Alpha now and in the future
will have it? What does "doesn't appear to handle properly" mean anyway?
Have you notified the GCC maintainers?

Also, whose idea was it to use '__inline__' instead of 'inline'?

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Yes, we can't apply this at this stage of the game. Just too many
port-specific changes.

[Charset iso-8859-1 unsupported, filtering to ASCII...]

On Tue, 11 Apr 2000, Kevin P. Neal wrote:

Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
release 1.4.1.

*** ./old/src/include/storage/s_lock.h  Wed Jan 26 00:58:33 2000
--- ./new/src/include/storage/s_lock.h  Sun Apr  9 23:56:46 2000
***************
*** 260,270 ****
--- 260,275 ----
#else /* i.e. not __osf__ */

#define TAS(lock) tas(lock)
#define S_UNLOCK(lock) { __asm__("mb"); *(lock) = 0; }

+ #if defined(__GNUC__)
+ static int              /* GCC on the Alpha doesn't appear to handle
+                            inlining of assembly with %0 or %1 properly.
*/
+ #else
static __inline__ int
+ #endif
tas(volatile slock_t *lock)
{
register slock_t _res;

__asm__(" ldq $0, %0 \n\

Any chance you could write a configure test that exposes this deficiency
rather than assuming that every GCC on every Alpha now and in the future
will have it? What does "doesn't appear to handle properly" mean anyway?
Have you notified the GCC maintainers?

Also, whose idea was it to use '__inline__' instead of 'inline'?

--
Peter Eisentraut Sernanders v_g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

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

"Kevin P. Neal" <kpneal@pobox.com> wrote:

Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
release 1.4.1.

Has anyone compared these to Ryan Kirkpatrick's efforts for Linux/Alpha?

regards, tom lane

On Wed, 12 Apr 2000, Tom Lane wrote:

"Kevin P. Neal" <kpneal@pobox.com> wrote:

Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
release 1.4.1.

Has anyone compared these to Ryan Kirkpatrick's efforts for Linux/Alpha?

I have not... I would glance over the patches if I could find them
(mailing list archive search turned up nothing or error messages). If some
one could forward them to me, I will give them a quick look over.
Most of the Linux/Alpha patches have to do with replacing int8,
int16, int32, and absoluteTime (not sure on the spelling of the last) to
Datum when passing to functions. Not 100% what that does, but seems to
solve a number of data corruption problems in passing data through the
utility adt functions. I plan to figure out more specificly what is going
on, but first I need to graduate from college. :)

---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------

I am unsure how to address this NetBSD/alpha patch.

Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
release 1.4.1.

There are lots of problems with the oid handling, and I can't get it
to successfully even begin to do a make runcheck, make runtest, or
make bigtest.

The results of a maketest are:
=============== Notes... =================
postmaster must already be running for the regression tests to succeed.
The time zone is set to PST8PDT for these tests by the client frontend.
Please report any apparent problems to ports@postgresql.org
See regress/README for more information.

=============== dropping old regression database... =================
ERROR: typeidTypeRelid: Invalid type - oid = 0
dropdb: database removal failed
=============== creating new regression database... =================
ERROR: createdb: database 'regression' already exists
createdb: database creation failed
createdb failed

Minimal patches are attached. They are enough to get 7.0 beta 3 up
and able to do minimal SQL queries. They are also required to get
it to build at all.
--
Kevin P. Neal http://www.pobox.com/~kpn/

"You're a slacker if you only give 90% 'cause you are afraid of the \
other 10%." -- Ross Smith Apr 22 1999 2:29am

[ Attachment, skipping... ]

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am unsure how to address this NetBSD/alpha patch.

I'd say leave it out for now. After I finish the fmgr revisions we
ought to have a better shot at porting to Alphas. I know most of
Ryan K's Linux/Alpha patches will go away with that.

I am only fifty or so functions away from updating everything that
accepts pass-by-value data types. There are a lot of pass-by-reference
data types not touched yet, but I think that those should work anywhere
that sizeof(Datum) == sizeof(pointer), so the vast majority of the
fmgr-related porting problems should be gone at that point. I will be
calling for port testers as soon as I commit those changes...

regards, tom lane

That was my guess, though his changes were s_lock related. Seems that is
an Alpha mess too.

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am unsure how to address this NetBSD/alpha patch.

I'd say leave it out for now. After I finish the fmgr revisions we
ought to have a better shot at porting to Alphas. I know most of
Ryan K's Linux/Alpha patches will go away with that.

I am only fifty or so functions away from updating everything that
accepts pass-by-value data types. There are a lot of pass-by-reference
data types not touched yet, but I think that those should work anywhere
that sizeof(Datum) == sizeof(pointer), so the vast majority of the
fmgr-related porting problems should be gone at that point. I will be
calling for port testers as soon as I commit those changes...

regards, tom lane

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

That was my guess, though his changes were s_lock related. Seems that is
an Alpha mess too.

Yes, it sounds like we will need some help from a certified Alpha guru
to make spinlock code that works reliably on multi-CPU Alphas :-(.

Anyone have friends in the right places at DEC?

regards, tom lane

On Mon, Jun 12, 2000 at 05:39:55PM -0400, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

That was my guess, though his changes were s_lock related. Seems that is
an Alpha mess too.

Yes, it sounds like we will need some help from a certified Alpha guru
to make spinlock code that works reliably on multi-CPU Alphas :-(.

If you leave the locking code as it is then PostgreSQL will dump core.

If you do not inline the locking code then the registers will not get
stomped (gcc bug), and PostgreSQL will function properly enough to
initialize itself and make it through a make install. Simple SQL
queries work ok, but I never tried anything fancy.

I haven't had the time to write up a test case to send to the GCC people.
Plus, the other (much larger) set of patches that a Linux/Alpha guy
wrote up did the same thing my patches did, but differently (-fno-inline
instead of patching the header file to not be __inline__).

The other change from me was to change the type for locks to be 32 bits
wide instead of 8 bits wide. All Alphas handle 32 bit quantities
naturally, but only some can handle 8 or 16 bit quantities. The assembly
code tries to do locks with 32 bit quantities, it doesn't make sense to
then try to lock an 8 bit quantity.

Guys, my patches are not complex. It doesn't take a guru to handle
my changes; otherwise I wouldn't have been able to write them.
--
Kevin P. Neal http://www.pobox.com/~kpn/

"You know, I think I can hear the machine screaming from here... \
'help me! hellpp meeee!'" - Heather Flanagan, 14:52:23 Wed Jun 10 1998

I think this had been addressed.

On Mon, Jun 12, 2000 at 05:39:55PM -0400, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

That was my guess, though his changes were s_lock related. Seems that is
an Alpha mess too.

Yes, it sounds like we will need some help from a certified Alpha guru
to make spinlock code that works reliably on multi-CPU Alphas :-(.

If you leave the locking code as it is then PostgreSQL will dump core.

If you do not inline the locking code then the registers will not get
stomped (gcc bug), and PostgreSQL will function properly enough to
initialize itself and make it through a make install. Simple SQL
queries work ok, but I never tried anything fancy.

I haven't had the time to write up a test case to send to the GCC people.
Plus, the other (much larger) set of patches that a Linux/Alpha guy
wrote up did the same thing my patches did, but differently (-fno-inline
instead of patching the header file to not be __inline__).

The other change from me was to change the type for locks to be 32 bits
wide instead of 8 bits wide. All Alphas handle 32 bit quantities
naturally, but only some can handle 8 or 16 bit quantities. The assembly
code tries to do locks with 32 bit quantities, it doesn't make sense to
then try to lock an 8 bit quantity.

Guys, my patches are not complex. It doesn't take a guru to handle
my changes; otherwise I wouldn't have been able to write them.
--
Kevin P. Neal http://www.pobox.com/~kpn/

"You know, I think I can hear the machine screaming from here... \
'help me! hellpp meeee!'" - Heather Flanagan, 14:52:23 Wed Jun 10 1998

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026