Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
Updated by: paj...@php.net
Reported by: stefan at whocares dot de
Summary: fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package: FPM related
Operating System: Linux (Debian for Sparc)
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
It was not badly meant, only trying to show you alternative.
I can't know nor judge the reason why you need v8 support, but have been
there many times in the past for my numerous projects.
We have to make decisions about which platforms we can support, and also
which we stop to support. There is nothing personal or aggressive in our
replies, only trying to explain the status and the reasoning behind it.
Sorry if you took it so badly, that's not the aim of our comments, or
mines in particular.
Previous Comments:
------------------------------------------------------------------------
[2010-11-17 01:09:51] stefan at whocares dot de
@paj...@php.net
Did it ever occur to you that I found this bug/problem because I
*specifically
wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd
have
certainly done so. Seeing that there already was a solution for Sparc v9
I
thought there might be interest in a solution that would allow PHP to
run on
older machines.
Hardware that maybe you're laughing about. But hardware that's still in
fairly
wide use. And, come to think of it, hardware that may also be the only
hardware
people in poorer countries than the one you're obviously living in are
able to
get their hands on. So I first asked and then got my hands dirty and
even
provided a possible solution - and one that could be easily implemented,
too.
And what for? Only to get ignorance and witty remarks in return. Well, I
almost
forgot that the PHP project has such a bad reputation when it comes to
bugs and
patches. Thanks for reminding me why. Now you can safely go back to your
ivory
tower and think about supporting next decade's hardware only. For my
part, I
promise to keep any bugs/problems in PHP I may find in the future to
myself and
will do the same for any patches I may come up with.
Btw: the boxes I'm talking about are running Linux (which you could have
seen by
looking at the "OS:" tag) and I really have no idea why you'd call that
a "soon
to be dead OS". If you have a problem understanding the difference
between a CPU
and an OS, may I ask what exactly makes you think you can give some
valuable
input here? As for the "cruelly needed developers" you mention: I don't
see why
you should need those as long as the community comes up with patches you
could
use. Ok, if you keep driving away people like this, I start to have an
idea as
to why ;)
------------------------------------------------------------------------
[2010-11-17 00:24:30] stefan at whocares dot de
As you may have read in my initial post, the compiler I (have to) use is
gcc
3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the
backend/port/tas/solaris_sparc.s file from the official PostgreSQL
sources:
! "cas" only works on sparcv9 and sparcv8plus chips, and
! requies a compiler targeting these CPUs. It will fail
! on a compiler targeting sparcv8, and of course will not
! be understood by a sparcv8 CPU. gcc continues to use
! "ldstub" because it targets sparcv7.
There they work around this by using a condition (for the SUN compiler)
like
this:
#if defined(__sparcv9) || defined(__sparcv8plus)
cas [%o0],%o2,%o1
#else
ldstub [%o0],%o1
#endif
and in their actual generic lock implementation
(src/include/storage/s_lock.h)
the code is this:
#if defined(__sparc__) /* Sparc */
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#define TAS(lock) tas(lock)
static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res;
/*
* See comment in /pg/backend/port/tas/solaris_sparc.s for
why this
* uses "ldstub", and that file uses "cas". gcc currently
generates
* sparcv7-targeted binaries, so "cas" use isn't possible.
*/
__asm__ __volatile__(
" ldstub [%2], %0 \n"
: "=r"(_res), "+m"(*lock)
: "r"(lock)
: "memory");
return (int) _res;
}
#endif /* __sparc__ */
Now my general idea was that if there's a reason for PostgreSQL to keep
that
code around, there might be a reason for PHP to do so as well. Obviously
I was
wrong there.
I also do not see the real advantage of 'cas' over 'ldstub' in the
current
scenario since both are atomic, both are supported (ldstub even on v7)
and both
do the job perfectly well.
------------------------------------------------------------------------
[2010-11-17 00:22:59] paj...@php.net
And you can still use FastCGI, btw. FPM is fairly new, and if new SAPIs
have to support soon to be dead OSes, then we will cruelly need more
developers to maintain everything :)
------------------------------------------------------------------------
[2010-11-17 00:03:57] f...@php.net
you should be able to compile with a gcc version which provides the
__sync_bool_compare_and_swap builtin function (>= 4.1).
It's supported by FPM. If with this version of GCC FPM is not able to be
compiled,
there is a bug in FPM. We'll take care of it.
It this a reasonable solution ?
------------------------------------------------------------------------
[2010-11-16 23:52:42] stefan at whocares dot de
Of course you may ask: because I'm porting PHP to the ReadyNAS platform
which
happens to use a SPARC v8 compatible CPU and thus *needs* the v8
instruction set.
Seeing that you've already made up your mind though, so I guess there's
nothing
more to add here. Makes me wonder why I can't get a response in > 24
hours as to
my patch but you can't wait for me to answer for like 4 hours.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
