
	Ok, here they are, the long awaited patches to make pgsql compile
once again on Linux/Alpha. It turned out that our old friend S_LOCK was
the problem. Apparently some one had pulled the S_LOCK assembly code out
of the static function that I put it in, and attempted to make it inlined
again (which is what broke it the first time around). On a whim, I
searched the net looking for an Alpha Assembly Programmer's Manual, and
see if it would help me any. I was lucky on both accounts. I found the
manual, and quickly figured out to make local labels. So... The S_LOCK
code for Linux/Alpha is finally safe for inlining! :)
	Here is the patch for ./pgsql/src/include/storage/s_lock.h

89c87
<                  bne   $0, already_set     \n\
---
>                  bne   $0, 3f          \n\
91c89
<                  bne   $0, already_set     \n\
---
>                  bne   $0, 3f          \n\
94,95c92,93
<                  beq   $0, stqc_fail       \n\
<         success: bis   $31, $31, %1        \n\
---
>                  beq   $0, 2f              \n\
>                  bis   $31, $31, %1        \n\
97,100c95,98
<                  jmp   $31, end	           \n\
<       stqc_fail: or    $31, 1, $0	       \n\
<     already_set: bis   $0, $0, %1	       \n\
<             end: nop      ": "=m"(*lock), "=r"(_res): :"0");
---
>                  jmp   $31, 4f	           \n\
>               2: or    $31, 1, $0	       \n\
>               3: bis   $0, $0, %1	       \n\
>               4: nop      ": "=m"(*lock), "=r"(_res): :"0");

	Though there are two other catches at the moment in compiling
pgsql on Alpha as well:

	1. The optimization flag, -O2, that is used, causes some code to
fail to compile with very strange errors, and it causes s_locks to jam.
Apparently this is due to the (somewhat) unstable nature of gcc/egcs on
Alphas at the moment. Turning it down to -O1 solves the problem and
everything works fine.

	2. C++ is pretty much broken on Linux/Alpha (Debian 2.0 at least),
due to missing header files. This means that libpq++ can't be compiled.
Either tell configure not to detect/use C++, or comment out the line in
interfaces/Makefile that causes libpq++ to be built.

	Beyond that, it should compile, install, and initdb just fine.
Regressions tests are a mixed bag at this time (see my seperate message
concerning this), but look promising.
	Here is the specs on my machine for reference:

XL366 Alpha w/192MB of RAM
Debian 2.0 Alpha (unstable)
Linux 2.0.34
gcc 2.91.57-5
glibc 2.0.7t-1

	I would be very interested in regression tests/results from
people running RedHat on thier Alphas. Would help me to narrow down what
is causing some of the regression test problems. If you do send them to
me, make sure to include what kernel, gcc, and glibc you are using.
Thanks.

	Ok, that should pretty much cover it for the 6.4 release on the
Linux/Alpha end. I would mark it as working, but still in need of further
work. TTYAL.

----------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                     |
|                                            --- Philippians 1:21 (KJV)    |
----------------------------------------------------------------------------
|  Ryan Kirkpatrick  |  Boulder, Colorado  | rkirkpat@nag.cs.colorado.edu  |
----------------------------------------------------------------------------
|               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
----------------------------------------------------------------------------


Fri, 30 Oct 1998 19:53:28 -0600 (CST)
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Patches for Pgsql on Linux/Alpha (RE: Last Call...)
> 
> 	Ok, here they are, the long awaited patches to make pgsql compile
> once again on Linux/Alpha. It turned out that our old friend S_LOCK was
> the problem. Apparently some one had pulled the S_LOCK assembly code out
> of the static function that I put it in, and attempted to make it inlined
> again (which is what broke it the first time around). On a whim, I
> searched the net looking for an Alpha Assembly Programmer's Manual, and
> see if it would help me any. I was lucky on both accounts. I found the
> manual, and quickly figured out to make local labels. So... The S_LOCK
> code for Linux/Alpha is finally safe for inlining! :)
> 	Here is the patch for ./pgsql/src/include/storage/s_lock.h
> 
> 89c87
> <                  bne   $0, already_set     \n\
> ---
> >                  bne   $0, 3f          \n\
> 91c89
> <                  bne   $0, already_set     \n\
> ---
> >                  bne   $0, 3f          \n\
> 94,95c92,93
> <                  beq   $0, stqc_fail       \n\
> <         success: bis   $31, $31, %1        \n\
> ---
> >                  beq   $0, 2f              \n\
> >                  bis   $31, $31, %1        \n\
> 97,100c95,98
> <                  jmp   $31, end	           \n\
> <       stqc_fail: or    $31, 1, $0	       \n\
> <     already_set: bis   $0, $0, %1	       \n\
> <             end: nop      ": "=m"(*lock), "=r"(_res): :"0");
> ---
> >                  jmp   $31, 4f	           \n\
> >               2: or    $31, 1, $0	       \n\
> >               3: bis   $0, $0, %1	       \n\
> >               4: nop      ": "=m"(*lock), "=r"(_res): :"0");
> 
> 	Though there are two other catches at the moment in compiling
> pgsql on Alpha as well:
> 

I have applied this.  However, we normally prefer context diffs. 
Fortunately, this patch had old and new rows, so it was almost the same
as a context diff.

It also only dealt with the alpha locking code, which he stated was
clearly broken, so application seemed good.  Some of your more agressive
patches may have to wait a week until 6.4 is released.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Fri, 30 Oct 1998 21:15:01 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [PATCHES] Patches for Pgsql on Linux/Alpha (RE: Last Call...)
On Fri, 30 Oct 1998, Bruce Momjian wrote:

> I have applied this.  However, we normally prefer context diffs. 
> Fortunately, this patch had old and new rows, so it was almost the same
> as a context diff.

	Sorry... I was in a bit of a hurry to get it out, and just grabbed
the a patch I had made a while back. It was so small and only covered one
file, I didn't think there would be much problem.

> It also only dealt with the alpha locking code, which he stated was
> clearly broken, so application seemed good.  Some of your more agressive
> patches may have to wait a week until 6.4 is released.

	By more aggressive patches, do you mean the optimizer and libpq++
advice, or did I miss something? Also, by 'he' and 'you' who do you mean?
I think you were speaking to more than one person, but I am not sure...
Please clarify, thanks. :)

----------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                     |
|                                            --- Philippians 1:21 (KJV)    |
----------------------------------------------------------------------------
|  Ryan Kirkpatrick  |  Boulder, Colorado  | rkirkpat@nag.cs.colorado.edu  |
----------------------------------------------------------------------------
|               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
----------------------------------------------------------------------------



Fri, 30 Oct 1998 20:39:38 -0600 (CST)
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Re: [PATCHES] Patches for Pgsql on Linux/Alpha (RE: Last Call...)
> On Fri, 30 Oct 1998, Bruce Momjian wrote:
> 
> > I have applied this.  However, we normally prefer context diffs. 
> > Fortunately, this patch had old and new rows, so it was almost the same
> > as a context diff.
> 
> 	Sorry... I was in a bit of a hurry to get it out, and just grabbed
> the a patch I had made a while back. It was so small and only covered one
> file, I didn't think there would be much problem.

Yes, I am just a little paranoid this close to final release, November
1.

> 
> > It also only dealt with the alpha locking code, which he stated was
> > clearly broken, so application seemed good.  Some of your more agressive
> > patches may have to wait a week until 6.4 is released.
> 
> 	By more aggressive patches, do you mean the optimizer and libpq++
> advice, or did I miss something? Also, by 'he' and 'you' who do you mean?
> I think you were speaking to more than one person, but I am not sure...
> Please clarify, thanks. :)

'he' and 'your' is you.  By more agressive, I mean things that could
affect other platforms, were we can't get 100% agreement from the other
developers that this is a safe change.

Let's see what you find, and what other say.  I don't want to apply
something at this point that is going to potentailly break another
platform, and the date/time routines have historically done this.

We can put them in a 6.4.* minor release, which I am sure we will have a
few weeks after the major.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Fri, 30 Oct 1998 21:53:14 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [PATCHES] Patches for Pgsql on Linux/Alpha (RE: Last Call...)
On Fri, 30 Oct 1998, Bruce Momjian wrote:

> Yes, I am just a little paranoid this close to final release, November
> 1.

	Understandable. Next time they will be in a much cleaner format.

> > 	By more aggressive patches, do you mean the optimizer and libpq++
> > advice, or did I miss something? Also, by 'he' and 'you' who do you mean?
> > I think you were speaking to more than one person, but I am not sure...
> > Please clarify, thanks. :)
> 
> 'he' and 'your' is you.  By more agressive, I mean things that could
> affect other platforms, were we can't get 100% agreement from the other
> developers that this is a safe change.
> 
> Let's see what you find, and what other say.  I don't want to apply
> something at this point that is going to potentailly break another
> platform, and the date/time routines have historically done this.
> 
> We can put them in a 6.4.* minor release, which I am sure we will have a
> few weeks after the major.

	Ok, I follow now, thanks for the clarification. The patch to the
Alpha S_LOCK code is the only patch I have at this time. I guess I should
have been clearer about the datetime problems. I do not have even a
prospective patch for those problems at this time, or plan to have the
time to even begin such a patch for at least a week or two. When I do get
such a patch, I will make sure to have a few other Linux/Alpha people test
it, as well as test what it does to a Linux/Intel compile of pgsql before
I post it to be added to the CVS tree. 
	The alpha S_LOCK patch only affected a single OS, and thought it
would be rather safe. Next time I will try and get it in earlier (last
week or two has been hectic with school :( ). Thanks for your
understanding. TTYL.

----------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                     |
|                                            --- Philippians 1:21 (KJV)    |
----------------------------------------------------------------------------
|  Ryan Kirkpatrick  |  Boulder, Colorado  | rkirkpat@nag.cs.colorado.edu  |
----------------------------------------------------------------------------
|               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
----------------------------------------------------------------------------


Sat, 31 Oct 1998 09:10:51 -0600 (CST)
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Re: [PATCHES] Patches for Pgsql on Linux/Alpha (RE: Last Call...)