On Tue, May 15, 2018 at 06:53:08PM +0100, Mark Rutland wrote: > On Tue, May 15, 2018 at 07:10:21PM +0200, Peter Zijlstra wrote: > > On Tue, May 15, 2018 at 04:43:33PM +0100, Mark Rutland wrote: > > > I *think* the table can encode enough info to generate atomic-long.h, > > > atomic-instrumented.h, and the atomic.h ordering fallbacks. I'll need to > > > flesh out the table and check that we don't end up clashing with > > > some of the regular fallbacks. > > > > Yes, details details ;-) > > > > > # name meta args... > > > # > > > # Where meta contains a string of: > > > # * B - bool: returns bool, fully ordered > > > # * V - void: returns void, fully ordered > > > > void retuns are relaxed > > How about: > > V - void: returns void, no ordering variants (implicitly relaxed)
Works for me. > > > # * I - int: returns base type, all orderings > > > # * R - return: returns base type, all orderings > > > # * F - fetch: returns base type, all orderings > > > # * T - try: returns bool, all orderings > > > > Little more verbose than mine, I think we can get there with X and XB > > instead of I and T, but whatever :-) > > Mhmm. I found it easier to do switch-like things this way, but it works > regardless. I'm a minimalist, but yeah whatever ;-) > > > # Where args contains list of type[:name], where type is: > > > # * v - pointer to atomic base type (atomic or atomic64) > > > # * i - base type (int or long) > > > # * I - pointer to base type (int or long) > > > # > > > add VRF i v > > > sub VRF i v > > > inc VRF v > > > dec VRF v > > > or VF i v > > > and VF i v > > > andnot VF i v > > > xor VF i v > > > xchg I v i > > > cmpxchg I v i:old i:new > > > try_cmpxchg T v I:old i:new > > > add_and_test B i v > > > sub_and_test B i v > > > dec_and_test B v > > > inc_and_test B v we might also want: set V v i set_release V v i read I v read_acquire I v (yes, I did get the set arguments the wrong way around initially)
