Recent changes to feature-requests

#1015 Feature request: disable codegeneration for atomics

Philipp Klaus Krause — Tue, 21 Apr 2026 13:06:29 -0000

status: open --> closed-fixed

#1017 Automatically narrow constants/literals types

Oleg Endo — Sun, 19 Apr 2026 13:14:07 -0000

As mentioned in [bugs:#3978], it looks more like a problem of the loop optimization.

If the loop optimization can't be fixed easily and you want to revert this change, then I guess this optimization could also be done in the mcs51 backend when expanding/emitting the multiplication operation? (by looking at the operands)

#1017 Automatically narrow constants/literals types

Philipp Klaus Krause — Sun, 19 Apr 2026 12:46:30 -0000

Unfortunately, we get a substantial code speed regression for mos6502: [bugs:#3978]

#1015 Feature request: disable codegeneration for atomics

Michael Golovanov — Fri, 17 Apr 2026 18:01:12 -0000

Ok, i built sdcc from atomics branch and make smoke tests for mcs51.

sdcc --version
SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/r4k/r5k/r6k/sm83/tlcs90/ez80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02/f8/f8l TD- 4.5.24 #16459 (Linux)
published under GNU General Public License (GPL)

Wow At first look its worked.

Details:
First test is try to build main.c with content
void main(void) {}

If no --norestartseqatomics compiler flag the size of firmware is
Name Start End Size Max

ROM/EPROM/FLASH 0x0000 0x00ae 175 65536
main.asm contains atomic related code like
; restartable atomic support routines
.ds 5
sdcc_atomic_exchange_rollback_start::
nop
nop

If add --norestartseqatomics compiler flag
Name Start End Size Max

ROM/EPROM/FLASH 0x0000 0x0068 105 65536

Second test on main.c

#include <stdatomic.h>

volatile atomic_flag lock = ATOMIC_FLAG_INIT;

void critical_section(void) {
    // Spin until we acquire the lock
    while (atomic_flag_test_and_set(&lock)) {
        // In a real application, you might do something here
        // to avoid tight spinning, or just wait for the lock.
    }

    // --- CRITICAL SECTION START ---
    // Example: Protected access to a shared resource
    // (e.g., updating a 16-bit variable, sending serial data)
    __critical {
        // Even within this lock, you might need __critical 
        // if interrupts can also try to grab this same lock.
    }
    // --- CRITICAL SECTION END ---

    // Release the lock
    atomic_flag_clear(&lock);    
}


void main(void) {
    while (1) {
        critical_section();
    }
}

Without --norestartseqatomics

Other memory:
Name Start End Size Max

PAGED EXT. RAM 0 256
EXTERNAL RAM 0 65536
ROM/EPROM/FLASH 0x0000 0x00d6 215 65536

Try to compile with --norestartseqatomics is failed (and there is expected behavior)
?ASlink-Warning-Undefined Global sdcc_atomic_exchange_gptr_impl referenced by module

#1015 Feature request: disable codegeneration for atomics

Philipp Klaus Krause — Fri, 17 Apr 2026 10:52:48 -0000

assigned_to: Philipp Klaus Krause

#1017 Automatically narrow constants/literals types

Oleg Endo — Mon, 13 Apr 2026 01:21:36 -0000

Nice, thanks!

#1017 Automatically narrow constants/literals types

Philipp Klaus Krause — Sat, 11 Apr 2026 17:59:52 -0000

Basically, we already had this optimization, it just was disabled due to code size regressions for some ports (in particular z80); looking at the big picture I now think it is worth it, and enabled it in [r16454].

#1017 Automatically narrow constants/literals types

Philipp Klaus Krause — Sat, 11 Apr 2026 17:59:40 -0000

status: open --> closed-fixed
assigned_to: Philipp Klaus Krause
Group: -->

#892 mcs51: codeseg/constseg lost high address byte

Oleg Endo — Mon, 06 Apr 2026 02:58:31 -0000

As it turns out, my idea to use something like #((___str_0 >> 16) + 0x80) for the high byte doesn't work. Although it compiles and assembles and links fine, it silently outputs #0x00 in the final code.

This is should be probably also fixed in the assembler/linker. Funnily, turning around the expression seems to work fine #((___str_0 + 0x800000) >> 16) . So use that for now.

Updated patch

#1017 Automatically narrow constants/literals types

Philipp Klaus Krause — Sat, 04 Apr 2026 13:07:20 -0000

Generic optimization based on generalized constant propagation, I'd say. In the front-end, we need that int, since too many things break otherwise. But later, we should narrow it (e.g. after checking that the operands are in the 0 to 255 range, and that the backend does have an unsigned 8x8->16 multiplication). Interestingly, for your example we do get okayish code for z180, but currently not mcs51 and stm8.