https://sourceforge.net/p/sdcc/wiki/Atomics/Recent changes to AtomicsenThu, 31 Oct 2024 08:37:33 -0000https://sourceforge.net/p/sdcc/wiki/Atomics/<div class="markdown_content"><pre>--- v1 +++ v2 @@ -9,9 +9,10 @@ For many targets, SDCC currently uses different representations, typically because it would be impossible or inefficient to use 0 for reset and 1 for set. Most targets do not have a dedicated test-and-set instruction. For those, we usually use a right-shift with indirect addressing instead, forcing different representations. For tlcs90, there is `tset`, but the shift is more efficient. For the Rabbits, `bit b, (hl)` is a privileged instruction, which makes `bit b, (hl) set b(hl)` an atomic test-and-set, but again, the shift is more efficient. -For mcs51 / ds390, `xch` is used, which only can reach part of the address space, so atomic_flag on ms51 and ds390 is possible only in some named address spaces. For f8 `xch` is used. +For mcs51 / ds390, we use an atomic_exchange implemented via restartable sequences. + Other atomics -- -Not yet supported. +Not yet supported. For a single hardware thread, they could be implemented based on restartable sequences (already supported in the backend for mcs51 / ds390 and used for atomic_flag). </pre> </div>Philipp Klaus KrauseThu, 31 Oct 2024 08:37:33 -0000https://sourceforge.netcf66c3f3593f57cd259b295baf35f7f31c7b9676https://sourceforge.net/p/sdcc/wiki/Atomics/<div class="markdown_content"><h2 id="volatile-sig_atomic_t">volatile sig_atomic_t</h2> <p>The type for which the C standard guarantees that it can be accessed as atomic entitiy, even in the presence of signals (interrupts).<br/> SDCC makes sig_atomic_t an unsiged char, i.e. a single byte. As long as volatile is implemented correctly, this should fulfill the C standard's requirements of reads and writes being atomic. No lock is required.</p> <h2 id="atomic_flag">atomic_flag</h2> <p>C requires this to be a "lock-free" atomic type. Currently the representations of the set and reset states are not fixed in the C standard. But many programmers expect reset to be 0 and set to be 1.<br/> For many targets, SDCC currently uses different representations, typically because it would be impossible or inefficient to use 0 for reset and 1 for set.<br/> Most targets do not have a dedicated test-and-set instruction. For those, we usually use a right-shift with indirect addressing instead, forcing different representations.<br/> For tlcs90, there is <code>tset</code>, but the shift is more efficient. For the Rabbits, <code>bit b, (hl)</code> is a privileged instruction, which makes <code>bit b, (hl) set b(hl)</code> an atomic test-and-set, but again, the shift is more efficient.<br/> For mcs51 / ds390, <code>xch</code> is used, which only can reach part of the address space, so atomic_flag on ms51 and ds390 is possible only in some named address spaces.<br/> For f8 <code>xch</code> is used.</p> <h2 id="other-atomics">Other atomics</h2> <p>Not yet supported.</p></div>Philipp Klaus KrauseFri, 22 Sep 2023 08:44:15 -0000https://sourceforge.netc83e64733e5736edb29a94a8e9d217f5c16bb085