hashlink
hashlink copied to clipboard
HaxeFoundation
Atomic operations.
The JIT implementation is based on what GCC emits for it's intrinsics. The C implementation is copy pasted from what I did for hxcpp.
See https://github.com/HaxeFoundation/haxe/pull/10610
I don't think this requires some specific opcodes, especially since the C version - which is supposed to be faster - is based on library function calls.
Good point about library calls on MSVC, I should replace those with the intrinsics.
But for GCC/Clang it already uses instrinsics, which do not call library functions: Godbolt
What's the status here? I'm willing to merge the hxcpp PR, but I'm unsure where we're at for HL.
That's a lot of code. I'm curious what's the rationale for supporting all 8/16/32/64 bits int values ? I think 32 + ptr only would be good enough. Also, if the hl_atomic inlines are only meant to support HL/C, maybe they should be in hlc.h and not hl.h ?
That's a lot of code. I'm curious what's the rationale for supporting all 8/16/32/64 bits int values ? I think 32 + ptr only would be good enough.
Hashlink has 8/16/32/64 bit int types, so I thought it made sense to already implement atomic operations for all of them even though there are no AtomicI8/16/64 types (yet).
Also, if the hl_atomic inlines are only meant to support HL/C, maybe they should be in hlc.h and not hl.h ?
Having them in hl.h could be useful if someone needs atomic operations when, for example, writing a hdll.
I think we should keep things more simple with only int32 atomics and using primitives instead of opcodes.
I've removed the 8/16/64 bit atomics, and switched everything to primitives. I have kept the pointer atomics, it'd be a shame if AtomicObject were only implemented for Java.
@ncannasse Should this be merged? I'm happy to handle the hxcpp and Haxe side of this, but we need a decision for HL first.
Last change before merge : I think we should directly add atomics to threads.c ;)