I am taking a look to the implementation of atomic_add_unless from the kernel.
From the parser, it seems there are two variants: one value returning (associated to atomic_add_unless) and a non-value returning one (associated to __atomic_add_unless). This seems to divert from other instructions where __atomic_X is the internal herd7's representation and atomic_X is defined in terms of the previous one in the .def file. There is nothing in the current .deffile about atomic_add_unless.
Unless I am missing something, I think we can remove the ret bool parameter in the constructor, always return a value (AFAIK this is the intended behavior of this instruction in LKMM), remove atomic_add_unless from the parser and define it in the .def file as atomic_add_unless(X,V,U) __atomic_add_unless(X,V,U).
I am taking a look to the implementation of
atomic_add_unlessfrom the kernel.From the parser, it seems there are two variants: one value returning (associated to
atomic_add_unless) and a non-value returning one (associated to__atomic_add_unless). This seems to divert from other instructions where__atomic_Xis the internal herd7's representation andatomic_Xis defined in terms of the previous one in the.deffile. There is nothing in the current.deffile aboutatomic_add_unless.Unless I am missing something, I think we can remove the
ret boolparameter in the constructor, always return a value (AFAIK this is the intended behavior of this instruction in LKMM), removeatomic_add_unlessfrom the parser and define it in the.deffile asatomic_add_unless(X,V,U) __atomic_add_unless(X,V,U).