Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, this is a great help. If you think it should be just one file we
can do that, but since the are separate instructions sets, separate
files I think still makes sense.
There is no reason for the i386 or AMD64 code to be different from what's
already tested on Linux --- the hardware's the same and the OS surely
doesn't make a difference at this level.
On linux you use gcc, which allows for inline assembly. So, the code is
already very different. Solaris cc doesn't support inline assemly
unless you use .il files (which is a management and build nightmare).
GCC's sparc backend is pretty awful, so it makes sense to embrace Sun
Studio 11 (it's free after all) to make Postgres run reasonably well on
sparc. While we're at it, it makes good sense to unify the methodology
of builds on Solaris (regardless of the architecture). "as" on Solaris
is shipped as a part of the core system -- so it is available without
Sun Studio and will interoperate with other gcc compiled objects for a
painless linkage.
Yes there is a reason to use different code on Opteron than on i386. It
requires less insutruction to do cas operations on opteron than on
80386. It is a tiny amount of code and well test on Solaris. It's in
solaris_XXX.s files, so clearly it is different already. i386 and amd64
have different instruction sets and different registers and thus
performing 32bit ops inside a 64bit program on opteron requires less
register "setup" -- you can save 2 or 3 instructions. Regardless, the
code I provided has far fewer instructions for the spinlocks than the
code that was there.
Does Solaris' assembler really support C-style "#if defined()"
constructs in .s files? That seems moderately unlikely.
Yes. That's the code I used to compile my stuff. Solaris's assembler
certainly allows CPP (it's the -P flag). It allows easily building dual
architecture builds from the same file with simply different flags to
compile instead of different build object sources. With the provided
files you can compile sparcv8plus (32bit) sparcv9 (64bit) i386 (32bit)
and amd64 (64bit).
(intel) as -K PIC -P tas.s
(amd64) as -K PIC -P -xarch=amd64 tas.s
(sparcv8plus) as -K PIC -P -xarch=sparcv8plus tas.s
(sparcv9) as -K PIC -P -xarch=sparcv9 tas.s
Separating the files out is as simple as making four different files
(three in this case as sparcv8plus and sparcv9 use the same asm for
32bit cas). I would still put them in seperate files as you may want to
add 64bit atomics at some point in the future and then the sparcv8plus
and sparcv9 stuff will differ. Since the code is so small in the first
place, it makes sense to me to put them in one file -- but that is
clearly just a personal preference.
My changes are just offered back. I made them because I wanted to get
Pg to compile on my box, but while I was at it, I believe I reduced the
complexity of code and offered (with pg_atomic_cas) an opportunity to
ascertain _who_ holds the lock when you have spinlock contention. (as
you could potentially cas the lock to the pg procpid instead of 1 at no
additional cost).
Best regards,
Theo
--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Ecelerity: Run with it. -- http://www.omniti.com/
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
