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