__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

[Toebs Douglass]

On 29/06/17 16:32, Andrew Haley wrote:
> On 29/06/17 15:23, Toebs Douglass wrote:

>> Actually, I have a bone to pick with them - the instruction to find out
>> the ERG size is privileged.  As such, unless you know better, you have
>> to assume the worst case of 2048 bytes.  This makes lock-free data
>> structure state and element structs huge.
> 
> What for?  Just assume that it's a cache line, and if that just happens
> to run slowly, so what?  The user has bought the wrong hardware.  And
> people who make hardware like that should be punished in the profit
> margin...

So, for example, the data structure state structures usually contain
pointers central to the data structure - for example, in the queue,
there is a pointer to the start and a pointer to the end of the queue.

These two pointers are in fact usually independent - enqueuing and
dequeues occur independently.

If the two pointers were in the same ERG, they would no longer be wholly
independent and performance would unnecessarily suffer.

I was actually wrong to say the elements would get big - the queue
elements actually already are using cache line padding only.

So what I see in fact is that the queue state structure has three
members with ERG padding - enqueue, dequeue and the ABA counter which is
used when elements are inserted into the queue.

>> It would be enough of a pain to have to make alignment run-time, but you
>> could do it if you could get ERG size - *but you can't even get ERG size*.
>>
>> Ahhh, face palm, etc.
> 
> I think you can blame that one on kernel architects: it should be possible
> for them to read the information and tell you.  Do they not?

I aim to be platform independent.  The library compiles on a *bare* C89
compiler - not even freestanding.  I think I might be able to find ERG
somewhere in /proc on the Linux port, but then I'd need to to link to
something to do I/O from /proc, and then what about on Windows?  there's
prolly a function call for it - but what about a bare metal embedded
platform?

On Intel I think I can call cpuid, no problems.

(I didn't realise until the last week I might need to - I assumed cache
line lengths on x86 were 32 bytes and on x86_64, 64 bytes.  This is not
the case - apparently x86 cache line lengths have varied between 32 and
128 bytes; and I'm not sure I can tell which target I'm on just from the
GCC predefines, so maybe I will need cpuid and then to do run-time
alignment).