Re: Atomic operations

[Paulo César Pereira de Andrade]

Em sáb., 6 de ago. de 2022 às 12:46, Marc Nieper-Wißkirchen
<marc.nieper+gnu@gmail.com> escreveu:
>
> Ping.

  Hi Marc,

> Paulo, I am not sure whether you have already answered this question.

  I believe if I replied I did miss the CC to the mailing list. But I remember
the original email.

> It would also be interesting to know whether the load and store operations 
> are always atomic (on all supported architectures).

  As long as using a ldr_* or str_*, ldi_* and sti_* most times need
a temporary for the pointer, unless a few special cases where the
pointer can be encoded in a single instruction.
  I believe only float/double load stores are not atomic in lib/jit_arm-swf.c,
where it implements fake registers in the stack.

> -- Marc
>
> Am Mo., 30. Aug. 2021 um 12:45 Uhr schrieb Marc Nieper-Wißkirchen 
> <marc.nieper+gnu@gmail.com>:
>>
>> Could we get instructions for atomic operations into GNU lightning?  At the 
>> moment, the only possibility to synchronize GNU lightning code in 
>> multi-threaded environments is to call external C code (which can be slow).

  I believe this could be done by only supporting gcc as the compiler,
and at first, implement slow versions that call the gcc builtins. Unfortunately
it would add a problem in that it would invalidate non callee save gpr registers
for the default implementation.

>> I'm thinking of a set of instructions that could be used to implement 
>> something in the scope of C's <stdatomic.h>.  In order to implement this, 
>> one can take the assembly that GCC generates on the various architectures 
>> (see also https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html).

  Implementing specialized versions based on generated assembly by
gcc should be mostly trivial.

  Do you have some proposal or idea of what to implement, and
lightning code names?

  I believe at first should implement only for wordsize values, and a very
small subset, at least enough to implement some kind of "fast" mutex.

>> Marc

Thanks,
Paulo