Even for targets with a unified address space, the asm generated looks wrong to me. Apparently the actual bytes of the characters in the string "AAA" are being used as the bytes of the void * and the uint32_t.
The option --norestartseqatomics has been implemented in th eatomics branch, and can be tested by users. Currently it only affects the mcs51 and ds390 ports, and mostly disables atomics support for these two ports. I did not call it --noatomics, and did not make it disable all atomics support; it just disables the restartable sequence support routines for atomics; depending on the target architecture and how the user uses atomics, stuff might work or not; basically, one could just try to compile...
The option --norestartseqatomics has been implemented in th eatomics branch, and can be tested by users. Currently it only affects the mcs51 and ds390 ports, and mostly disables atomics support for these two ports. I did not call it --noatomics, and did not make it disable all atomics support; it just disables the restartable sequence support routines for atomics; depending on the target architecture and how the user uses atomics, stuff might work or not; basically, one could just try to compile...
Feature request: disable codegeneration for atomics
The option --norestartseqatomics has been implemented in th eatomics branch, and can be tested by users. Currently it only affects the mcs51 and ds390 ports, and mostly disables atomics support for these two ports. I did not call it --noatomics, and did not make it disable all atomics support; it just disables the restartable sequence support routines for atomics; depending on the target architecture and how the user uses atomics, stuff might work or not; basically, one could just try to compile...
--norestartseqatomics option, RFE #1015.
Allow recreation of file structure for opcode experiments from map table.
ldw y, z opcode fix for opcode map optimization experiments.