tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] [PATCH] stdatomic: ld/st/xchg/cmpxchg on simple types


From: Dmitry Selyutin
Subject: Re: [Tinycc-devel] [PATCH] stdatomic: ld/st/xchg/cmpxchg on simple types
Date: Fri, 19 Mar 2021 23:12:48 +0300

struct foo {
        uint8_t a;
        uint16_t b;
};
struct foo x, y;
memset(&x, 1, sizeof(x));
memset(&y, 2, sizeof(y));
x.a = y.a = x.b = y.b = 0;
atomic_compare_exchange(&x, &y, y);

This is a good question; for the case you presented, things will work, since the padding itself is taken into account upon memset(). I'm not sure of the case if you omit the memset, though; C doesn't allow to compare the structures. I'd assume binary equivalence, if not mentioned otherwise, but I'll check this case.

I also thought about it, and even wanted to supply a real integer into type_size() routine, but then decided to keep things simple for the first patch, and stick to exact memory match, since it was the simplest thing to do.

I'll check the behavior of other compilers and will update in a separate patch. Actually, when I checked it, I was kinda surprised it even works for types other than integers.

It also leaves a room for other questions, like "say float is the same size as uint32_t, should we handle the trap representation?". And I'm not sure whether the answers are evident. The binary equivalence was the best shot I could think of.

All other answers potentially lead to additional code generation. Also, thinking of non-lock-free-atomics: IIRC these are usually handled by hashing the addresses along with locking and memcmp/memset. This is also that should be checked.

When I have time, I'll write some tests which check at least usual integers; as for more complicated cases, I'll check them afterwards.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]