Libatomic support

[Daniel Cederman]

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

Thanks for the comment. I thought it would be a quick fix to add 
support, but looking at the code that gcc generates for _Atomic struct's 
I do not really trust it to be correct. And on embedded platforms it is 
probably better to get an undefined reference error and make a custom 
solution than to add locks indirectly. So I will put this on hold.

On 2014-10-02 07:50, Sebastian Huber wrote:
> 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?
>

-- 
Daniel Cederman
Software Engineer
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758665
cederman at gaisler.com
www.Aeroflex.com/Gaisler