Re: Atomic operations

[Paulo César Pereira de Andrade]

Em sex., 12 de ago. de 2022 às 08:15, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade@gmail.com> escreveu:
>
> Em qui., 11 de ago. de 2022 às 17:52, Marc Nieper-Wißkirchen
> <marc.nieper+gnu@gmail.com> escreveu:
>
>   Hi Marc,
>
> > PS: This document may be helpful as well: 
> > https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html.

  My idea is to keep at least the first implementation as simple
as possible.

>   Right now, my idea of what should be done would be to have a
> jit_casr(bool_return_in_register, address_in_register,
> new_value_in_register, old_value_in_register);
>
>   It would need a new pattern of 4 registers instruction, as only
> the first one is modified. The current qmul* and qdiv* ones put
> result in the first two register arguments.
>
>   And while at that, also have a:
>
> jit_tasr(old_value_in_register, address_in_register, new_value_in_register);
>
>   Likely can have the _c, _s, _i, and _l modifiers, or have only a 32
> bit variant.

  At first "test and set" is only cheap on x86*, and would require very complex
code, and even loops on some architectures. It should also not be friendly to
cache and end up wasting too much cpu.
https://godbolt.org/z/WPsPzv66c

>   Very few cpus should not have some construct for it. For those, we just add
> a software fallback with some kind of spin lock. In either case,  we "cheat" 
> and
> look at what assembly gcc generates or the kernel uses for the
> equivalent construct.

  For the moment I am considering only a:

jit_casr(jit_int32_t bool_reg_return, jit_int32_t address, jit_int32_t
old_val, jit_int32_t new_val);

where:
* bool_reg_return would be true if it did swap, false otherwise;
  any loop, until it returns true would need to be explicitly generated.
  This also makes it easier to implement a "try lock" logic.
* address is the address in a register
* old_val is the expected old value in a register
* new_val is the expected new value in a register

could implement a jit_casi where the address argument could be an
immediate value.
At first I would avoid it, because it likely would need a temporary,
and better to
have the code implementing any loop choosing what register to use for
the address,
and it might still be required temporaries on some architectures even
receiving all
arguments in registers.

  About pairs, it is in my low priority TODO complex numbers support :-)

>   About the ABA problem, we ignore it. Just have some note, describe the issue
> and how to avoid it. I would suggest using it with the address_in_register 
> value
> as a special lock, not the actual variable.

Thanks!
Paulo