Re: PlayStation 2 problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PlayStation 2 problems
Date: 2003-11-02 23:25:07
Message-ID: 5518.1067815507@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I've tried PG 7.4 on a PlayStation 2/Linux. This is a kind of mips
> machine but apparently doesn't like the existing mips assembly code
> (illegal instruction errors).

Yes, that was known already --- apparently it uses a variant MIPS chip
with no spinlock instructions. The note in the Supported Platforms list
describes what Permaine Cheung had to do to work around this in 7.3.
I'm not surprised that the details are a bit different in 7.4.

> I've also tried --disable-spinlocks to turn
> off the use of the assembly code, without success.

That is a deficiency of Bruce's --disable-spinlocks implementation that
I already knew about --- it should be possible to use the switch to
disable spinlocks on a platform that the code thinks has them, but it
isn't. It looked not very practical to fix this until after the
spinlock code reorganization that Bruce is holding for 7.5, so I planned
to leave the issue alone until that patch is applied.

> The old report from 7.3 has the comment
> #undef HAS_TEST_AND_SET, remove slock_t typedef
> I've additionally had to disable the mips tas_dummy in s_lock.c.

Hmm, shouldn't much of that file be #ifdef HAS_TEST_AND_SET anyway?

> (How is this tas_dummy code reached anyway?)

Via the assembler label "tas:". Not sure why these routines are coded
that way, but I'm disinclined to fool with them.

> Also, we need a newer version of config.guess to support this platform.

Yeah, I was thinking the other day that we should have updated
config.guess before starting the beta cycle. At this point I feel it's
too late for 7.4 though --- inserting a new config.guess at this point
would risk invalidating existing port reports.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2003-11-03 00:15:07 Re: Experimental patch for inter-page delay in VACUUM
Previous Message Tom Lane 2003-11-02 23:06:45 Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL