On 24 August 2012 22:35, Jakub Jermar <[email protected]> wrote: > On 08/24/2012 11:34 AM, Jiří Zárevúcky wrote: >> On 23 August 2012 00:45, Jakub Jermar <[email protected]> wrote: >>> - non x86 platforms are missing atomic_cas_* implementations (the >>> first step would be to make all platforms at least build using just >>> dummy implementations, the next step would be to provide >>> functional, but perhaps still limited implementations for these); >>> for example, armv4 does not have atomic instructions, so all one >>> can do is disable interrupts and then do a non-atomic cas >> >> What about GCC builtins? I'd imagine these are implemented in the best >> possible way on all supported platforms. >> There is GCC-specific code all around the system anyway, Clang mirrors >> its features well, and I don't see the need (or sense) to target any >> other compiler. > > Among others, GCC provides: > > TYPE __sync_fetch_and_add (TYPE *ptr, TYPE value, ...); > TYPE __sync_add_and_fetch (TYPE *ptr, TYPE value, ...); > TYPE __sync_val_compare_and_swap (TYPE *ptr, TYPE oldval TYPE newval, ...); > TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...); > void __sync_lock_release (TYPE *ptr, ...); > > These are basically those needed by HelenOS; compare_and_swap() is newly > required by CHT. > > I can see some potential problems though, for example, the gcc infodoc says: > > Not all operations are supported by all target processors. If a > particular operation cannot be implemented on the target processor, a > warning will be generated and a call an external function will be > generated. > > Which suggests that we could end up implementing some of the above anyway. >
If an operation cannot be implemented on the target processor, then you can't implement it yourself anyway. A single locked fallback function for every operation is still a big improvement over custom bits of potentially untested assembly code for every architecture. > Another problem is that some of the builtins above have slightly > different semantics wrt. memory barriers than the primitives already > used in HelenOS so that switching over may require some refactoring. It > is not clear whether it wouldn't be easier to implement the missing > functionality instead. > What about the newer __atomic_* builtins that specify memory semantics? I find it unlikely that the HelenOS variant is very different from all of the provided possibilities. http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/_005f_005fatomic-Builtins.html#_005f_005fatomic-Builtins _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
