Uwe Lienig <Uwe.Lienig@fif.mw.htw-dresden.de> wrote:

> During configure everything went well, but stucks during compile with
> 
> gmake[3]: Entering directory
> `/usr/src/local/postgresql/postgresql-7.0.3/src/backend/storage/buffer'
> gcc -I../../../include -I../../../backend   -O2 -pipe -Wall
> -Wmissing-prototypes -Wmissing-declarations -I../..   -c -o s_lock.o
> s_lock.c
> s_lock.c:71: warning: no previous prototype for `s_lock'
> s_lock.c: In function `s_lock':
> s_lock.c:74: warning: implicit declaration of function `TAS'
> s_lock.c: At top level:
> s_lock.c:149: warning: `tas_dummy' defined but not used
> {standard input}: Assembler messages:
> {standard input}:220: Error: opcode requires -mips2 or greater `ll'
> {standard input}:222: Error: opcode requires -mips2 or greater `sc'
> 
> Going into the docs i realized, that there is a hint that TAS (dunno,
> what it is) isn't supported (at all ?? - or not implemented). What about
> getting postgresql running on pmax under 1.5 ?

Well, the short answer is: TAS stands for Test And Set.  It needs
to be an atomic instruction in the hardware.  It is obviously not
implemented currently in PostgreSQL at the moment.  I do not know
if the pmax has the required hardware to do it. (I personally know
that Sparc's, PC532's, and m68k's do, and that there are others,
but I haven't dealt with them directly.)

I wrote this little piece of code for the PC532 some time ago, and
I'd be happy to do it for the pmax as well, provided I knew any
MIPS assembly and the MIPS processor had the hardware support. I
have hearsay evidence that MIPS does not have the hardware to do
this.  If that is true, it does not mean that the pmax will never
run PostgreSQL, just that it may never run it well, or quickly, if
someone goes to the trouble of fixing it.

The PostgreSQL system has several processes (1 per active query?)
that need to read and write to a shared area of memory.  However,
they can't all read and write at the same time, or you'd have a
pile of corrupt memory, rather than a database, so PostgreSQL uses
a small bit of assembly code to keep all the processes from stepping
on each other.

If that assembly code is not able to be written, (because the
processor has no atomic read/modify/write hardware) there are other
ways around the problem.  For example, you could just turn off all
the interrupts while the critical code is being executed.  Or you
could get the kernel to do this for you by doing a system call.
However, PostgreSQL does it with a small bit of an assembly macro
because it needs to be done often, and it needs to be very quick.
Using these other methods (or other methods) tend to be much slower,
and in some cases can have bad side effects for the rest of the
system.

Anyway, if someone can point me to a good assembly language reference
for the pmax, I'll see if I can code something up.  (Or see if it
is possible to code something up.)

Jon