Re: GAtomic ABI and win32 implementation

At 17:45 28.02.04, Sebastian Wilhelmi wrote:
Moin Hans,

> > >       g_atomic_int_compare_and_exchange_fallback
> > >       g_atomic_int_exchange_and_add_fallback
> > >       g_atomic_int_get_fallback
> > >       g_atomic_pointer_compare_and_exchange_fallback
> > >       g_atomic_pointer_get_fallback
> >
> >They have to be exported in general, as we need them for e.g. non-gcc
> >compilers, which can't do the inline assembler stuff.
> Two of them were not exportable due to missing implementation, i.e.
> ;       g_atomic_int_get_fallback
> ;       g_atomic_pointer_get_fallback
> seem to be missing with my current configuration. Do you have tested the
> none- GCC case so that this is just a win32 issue, I'm looking for ?

Fixed in CVS. Thanks.
Still wondering (I' m probably too old for so much #ifdefs; and all these asm doesn't improve readability either ;-)

- Should the ABI really differ depending on the compile time switch,
- Don't we want the fallback implementations in any case ?

> >ON win32 however
> >they are not needed, if you use the InterLocked* functions.
> I'd rather like to implement all of them on win32 with the Interlocked*
> family of functions, rather than putting any win32 api into glib headers.
> At least The GIMP and Dia are compiled on win32 with forced include
> of msvc_recommended_pragmas.h , especially in this case :
> #pragma warning(error:4013) /* 'function' undefined; assuming extern
> returning int */
> which would break the build if noone includes <windows.h> before <glib.h>.
> OTOH including windows.h would not only break due to namespace clashes but
> also weaken the cross platform API glib provides ...

I see. In that case however you might actually be better off just using
the generic i486 functions. What's wrong with that? Using the
InterLocked* Functions in gatomic.c will be slower because of two nested
functions calls instead of an inline function. And the i486 version is
correct, too. The only problem of course is, if you compile with
non-gcc. I think, that's your motivation.....

Yepp, but also the ABI between the msvc and the mingw build should be compatible, so both need to export the same functions.

In that case you could try the attached patch (untested..):

> >You might have to add casting (no idea, I have no windows around).
> >
Yeah, but this one appeared to be simple. I also added some check for pointer being 32-bit, cause there is no InterlockedExchangeCompareExchangePointer (but InterlockedCompareExchange() does take PVOID, I'm eager to see this fixed in win64 :)


-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]