> Here is a minimal API, albeit written for Scheme: https://srfi.schemers.org/srfi-230/srfi-230.html. What is an atomic (fixnum) box there should be word-sized memory location in GNU lightning. Atomic pairs (two words) are important for some algorithms. If they are not easily implementable on a particular architecture, GNU lightning should report this so that the user can call C library routines (from stdatomic) or GCC builtins themselves.
>
> As for GNU lightning instructions, we would probably at least need the following instructions (for word-sized integers):
>
> - loads and stores with relaxed memory order (if I have understood correctly, we can use the usual GNU lightning load/store instructions)
> - loads with acquire memory order
> - stores with release memory order
> - swap (load and store) with relaxed memory order
> - swap (load and store) with acquire-release memory order
> - compare-and-swap with relaxed memory order
> - compare-and-swap with acquire-release memory order
If lightning were to provide such primites, I believe it should
only "make a contract" of supporting strong compare-and-swap,
not on shared memory (a different process might die with the
lock held), to allow some kind of mutex implementation, what
could be expensive if there are too many waiters spinning.
I am not sure whether I have understood your "contract".
In any case, if a mutex is needed we could just call the GCC-provided software implementation in libatomic ([1]) (after checking that libatomic's ABI is supposed to be stable and works with different compilers as well). Alternatively, we can roll out our own hash table of mutexes where the hash is calculated from the memory address that is to be accessed atomically in software.
Still not trivial to get it on all supported ports, at least with the same
semantics, because if need to implement in an external function call,
it would need to save/restore all JT_R* and JIT_F* registers in the
worst case. Most times could just inline what gcc generates.
As atomic operations are usually quite costly, the overhead of saving and restoring registers is probably not too bad.
> And the same, if supported, for double-word-sized memory operands.
>
> And then the following arithmetic operations (in relaxed and acquire-release semantics):
>
> - fetch-add
> - fetch-sub
> - fetch-or
> - fetch-xor
> - fetch-and
>
> And then an instruction to emit a memory order (release, acquire, acquire-release, sequential consistency) as atomic_thread_fence in stdatomic.h.
> To simplify the interface, it may make sense to offer all operations (but the thread fence instruction) only with relaxed semantics so that the programmer has to emit thread fence instructions explicitly.
The simplest way to implement it is to have it have some PIC code
implementing it, and use two jit_jmpr to/from the code, but lightning
would still treat the jit_jmpr as function calls, that is, invalidate non callee
save registers.
If internally, lightning uses an instruction different from jit_jmpr to "call" the atomic code, it can have more detailed knowledge about the registers that have to be saved.
As long as using only jmpr, and not modifying registers, should be
enough to call jit_live() once "returning" for any non callee save register
used in the construct, or that must be alive for other use.
Thanks!
Paulo