Port-sparc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Berkeley db 4.8 and newer, and sparc



On Thu, 28 Oct 2010, Hauke Fath wrote:

> At 18:45 Uhr +0000 28.10.2010, Eduardo Horvath wrote:

> >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?

It's running as a V8 binary.

> >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?

gcc uses __arch64__ to indicate a 64-bit binary and __sparc_v9__ to 
indicate the v9 instruction set is in use.  With standard usage they aree 
equivalent.  However, if you give gcc fancy flags you can generate 32-bit 
v9 binaries.  But that's never done in practice.

In this case you are concerned about the instrucion set so I would queue 
off __sparc_v9__.  Most other cases are concerned with 32/64 bit code 
distinctions and use __arch64__ (which is also used for other 64-bit 
machines such as amd64.)

> >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?

Yes.

Eduardo


Home | Main Index | Thread Index | Old Index