On 18 June 2015 at 19:32, Mark Burton <mark.bur...@greensocs.com> wrote:
> for the 1<<size thing - I think that code has been used elsewhere, which is a
> little worrying - I’ll check.
>
>> On 18 Jun 2015, at 17:56, Peter Maydell <peter.mayd...@linaro.org> wrote:
>>
>> On 18 June 2015 at 16:44, <fred.kon...@greensocs.com> wrote:
>>> + uint64_t oldval, *p;
>>> + p = address_space_map(cs->as, paddr, &len, true);
>>> + if (len == 8 << size) {
>>> + oldval = (uint64_t)env->exclusive_val;
>>> + result = (atomic_cmpxchg(p, oldval, (uint64_t)newval) ==
>>> oldval);
>>
>> You can't do an atomic operation on a type that's larger than
>> the pointer size of the host system. That means that for
>> code that isn't host specific, like this, in practice you
>> can't do an atomic operation on a larger size than 4 bytes.
>>
>
> I thought they were polymorphic across all types, I didn’t notice
> the caveat of the size, sorry about that. That makes things more
> entertaining :-)
It's polymorphic across most types... It's been suggested
that the macros should refuse types with size > ptrsize
on all systems, so you don't have to get bitten by a
ppc32 compile failure after the fact, but I don't think that
anybody's written the patch yet.
-- PMM
