Re: [v3] atomics

["Lawrence Crowl" <crowl at google dot com>]

On 4/18/08, David Daney <ddaney@avtrex.com> wrote:
> Lawrence Crowl wrote:
>
> > On 4/18/08, David Daney <ddaney@avtrex.com> wrote:
> >
> > > David Daney wrote:
> > >
> > >
> > > > Jakub Jelinek wrote:
> > > >
> > > >
> > > > > On Fri, Apr 18, 2008 at 10:51:33AM -0700, David Daney wrote:
> > > > >
> > > > >
> > > > > > At this point I don't really have an opinion as to how to fix the
> > > > > >
> > > > >
> > > >
> > > problem.  One thought that comes to mind is to change the definition of
> > > atomic_flag so that the size of the atomic variable is appropriate for
> the
> > > target architecture (32 bits in the case of MIPS)
> > >
> > > >
> > > > > Best is to add support for the 8 and 16-bit sync builtins.
> > > > > See e.g. sparc or s390 backends how it can be done using 32-bit
> > > > > compare and swap instruction.
> > > > >
> > > > >
> > > > >
> > > > Thanks Jakub,
> > > >
> > > > Would it make sense to handle this in a more generic manner where the
> > > >
> > > operations are expanded?
> > >  Well, that's not likely to work...
> > >
> > >
> > >
> > > > Or should each target just write patterns for 8 and 16 bit operations
> if
> > > >
> > > they don't natively support it?
> > >  I will do this for MIPS.
> > >
> >
> > The intent was that either implementations expand the size of the atomics
> > to the minimum supported size or implement the operation with a
> > compare-and-swap on the word containing the atomic.
> >
> >
>
>  Thanks,
>
>  Which would you recommend for this case?
>
>  Changing the size of the atomics could cause increased memory usage,
> implementing the atomic operations on sub-words would increase code size.
>
>  Changing our minds later would change the ABI.

It depends on the run-time costs of the two operations.
If they're close, definitely go with the smaller memory footprint.
This has the advantage of matching the layout of naive code.

-- 
Lawrence Crowl