Libatomic support

[Sebastian Huber]

On 01/10/14 16:20, Daniel Cederman wrote:
> I'm looking at GCC's libatomic, which provides software emulation of atomic
> operations that are not supported by hardware. It does this by using a
> compare-and-swap loop, or, failing that, using locks. At the moment it is not
> selected for compilation for RTEMS since it requires operating system (or
> architecture) support for the locks. It needs support for two types of
> lock/unlock operations. Here is a cut-and-paste from the libatomic_i.h file in
> libatomic:
>
>  >/* Locking for a "small" operation.  In the bare-metal single processor
>  >   cases this could be implemented by disabling interrupts.  Thus the extra
>  >   word passed between the two functions, saving the interrupt level.
>  >   It is assumed that the object being locked does not cross the locking
>  >   granularity.
>  >
>  >   Not actually declared here so that they can be defined static inline
>  >   in a target-specfic <host-config.h>.
>  >
>  >UWORD protect_start (void *ptr);
>  >void protect_end (void *ptr, UWORD);
>  >*/
>  >
>  >/* Locking for a "large' operation.  This should always be some sort of
>  >   test-and-set operation, as we assume that the interrupt latency would
>  >   be unreasonably large.  */
>  >void libat_lock_n (void *ptr, size_t n);
>  >void libat_unlock_n (void *ptr, size_t n);

Yes, libatomic is for targets lacking proper hardware atomic operations.  So 
protect_start/end() should use rtems_interrupt_disable/enable().  For 
libat_lock_n/unlock_n() you can simply use the allocator lock for example.

I would not put too much time into this.  Who needs this stuff?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.