The two potential issues with stdatomic.h in general are: 1) it is not mandated by freestanding implementations (that is, even the header is not mentioned at all), so de iure one cannot use stdatomic.h, for example, in OS development; 2) on some platforms, this might be not implementable at all, at least not without some tricks like disabling interrupts, so a kernel support is needed.
De facto, however, for most platforms in use, this works regardless of the fact whether implementation is hosted or not; if we support more exotic cases, the code generator for these platforms may simply end up with compile-time error, or at least can put some unresolved references. Also the whole point of hosted/freestanding does not apply to tcc, because tcc does not have option to operate in freestanding mode. ср, 27 янв. 2021 г., 06:56 Kyryl Melekhin <k.melek...@gmail.com>: > Elijah Stone <elro...@elronnd.net> wrote: > > > On Tue, 26 Jan 2021, Kyryl Melekhin wrote: > > > > > Also while atomics are probably better solution so using something > like > > > mutex or spinlock, they are platform dependant > > > > They're no more platform-dependent than addition. Obviously they do > need > > support from the CPU, but so does everything else. They don't depend on > > any OS-specific facilities or anything like that. > > > > > they just kind of produce code smell > > > > How's that? > > Absolutely agree with you that atomics are nothing more but just cpu > instructions. I probably think this way because I always try to not use > any GNU compiler extensions or anything too fancy that would require use > of extra features. So for example just calling pthread_mutex_lock() does > not require anything from compiler other than to call the function. > I think part of contributing to this midset is that I only write C99 > code, and tcc being not able to support atomics until now assured me > not to use them. It's hard to accept some feature like this one after > avoiding it for very long time. I might come to change my mind. > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
