Re: Berkeley db 4.8 and newer, and sparc

[Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>]

At 18:45 Uhr +0000 28.10.2010, Eduardo Horvath wrote:
>On Thu, 28 Oct 2010, Hauke Fath wrote:
>
>> o What is the equivalent of the above assembler code for SPARC v7?
>> o How does that equivalent work with v8 and v9 (sparc32 mode) cpus? With MP
>> machines?
>> o Or do we have to build specifically for the target cpu?
>> o Do we have any #defines besides __sparc__ and __sparc64__ to tell us
>> which cpu gcc creates code for?
>> o Is there a completely different way that I cannot see?
>
>V7 does not have any memory ordering insructions.
>
>V8 added STBAR and FLUSH.  FLUSH is only required for self-modifying code.
>STBAR decodes to a noop on v7 machines, so they can be added to code
>wihout affecting v7 machines.

That's a relief. I suspected I might have to distinguish the two.

>On SPARC V9 machines we run 32-bit processes with the TSO memory model so
>no barrier instructions are needed.  32-bit binaries do not use v9
>instructions.

That's even better!

>64-bit processes use whatever memory model is encoded in the ELF header or
>RMO which means we do need all the fancy memory barrier instrucions.

What would a 32 bit binary do when run on a 64-bit sparc v9?

>You should be able to use __arch64__ to compile in the memory barriers
>only for 64-bit code.

Is that a universal gcc #define, or something specific to NetBSD?

>If you're running V8 in PSO mode the LDSTUB does not need memory barriers.
>An atomic unlock using STB does however:
>
>unlock:
>       stbar
>       stub    %g0, [lock]

-- does that apply to the

#define MUTEX_UNSET(tsl)        (*(tsl) = 0, MUTEX_MEMBAR(tsl))

code from mutex_int.h?

Now I have something to work from, thanks!

        hauke

--
"It's never straight up and down"     (DEVO)