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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
