Recent changes to support-requests

[STM8] Error in evaluating constant expressions in linux

2026-02-07T11:58:42.022000Z

I have attached an LED blink program that I wrote for an STM8S microcontroller. It contains an expression which is evaluated at compile time:

ldw     y, #(F_CPU / 20200 / 3)

F_CPU is 16_000_000. This expression should evaluate to 264. Which it does while building on a windows host. But when I'm building on a linux host (specifically arch linux), I noticed that it is evaluating to 0x14CD (which I noticed from the .lst file).

Again, it works correctly on windows, the error comes only while building on linux (arch linux).

PFA
.s, .lst, .rel files

Here is my host environment:

OS: Arch linux
SDCC version: 4.5.0
Target device: STM8S103

Thanks

#208 Something goes wrong when building uCsim

2026-01-29T10:08:36.235000Z

status: open --> closed

#210 Two inline assembly issues.

2026-01-04T14:55:23.333000Z

I suggest to change the definition of CLOCK_HZ to 125000000UL to indicate it is a long integer value. For SDCC all normal integers are 16 bit wide. It looks like it is using 24 bit here.

Further, note that there are no PUSH/POP A instructions, only PUSH/POP ACC.

Those sdcc_atomic_exchange_rollback functions are needed to rollback atomic access evaluation when an interrupt occurs so it can re-evaluate the atomicity. They are generated along with the interrupt vector table when main() is compiled and must live at specificly aligned addresses. Did you forget to add a prototype for void isr_timer0(void) __interrupt(1) in the file that contains your main()?

Finally, did you notice that isr_timer0() already saves and restores ACC and PSW?

Two inline assembly issues.

2026-01-01T14:13:06.149000Z

I am writing timer0 interrupt code to reprogram the timer0 for accurate timekeeping.
But the 8051 inside a network-switch SOC is running at high frequency of 125 MHz.

I encounter two issues.

Issue 1: Calculation is wrong inside the inline-assembly when using large numbers.

Defines and C functions.

// System frequency which is also CPU frequency
#define CLOCK_HZ 125000000
// Timer0 is divided by 12
#define TIMER0_CLK_DIV 12
// Number of Timer0 Interrupts per second.
// Minimum must be 158 because of the high clock frequency and 16-bit timer resolution.
#define SYS_TICK_HZ 200
// Number of timer0 counts needed to get SYS_TICK_HZ
#define SYSTICK_TIMER0_VALUE (CLOCK_HZ / TIMER0_CLK_DIV / SYS_TICK_HZ)

// Number of Timer0 ticks missed while reprogramming.
#define TIMER0_REPROGRAM_TIMER_TICK_COUNT (12 * 4 / TIMER0_CLK_DIV)

// Value programmed into TIMER0.
#define TIMER0_REPROGRAM_VALUE  (0x10000 - SYSTICK_TIMER0_VALUE + TIMER0_REPROGRAM_TIMER_TICK_COUNT)

// C-code
inline void update_timer0(void) __naked {
    __asm
    ; Turn off global interrupts, to ensure code below is not interrupted.
    clr _EA
    ; Store ACC, PSW both are overwritten.
    push a
    push psw
    mov a, #(TIMER0_REPROGRAM_VALUE & 0xFF)
    clr _TR0
    ; Timer0 is disables, every instruction below this line is counted as delay
    ; what the TIMER0 could advance while reprogramming.
    add a, _TL0
    mov _TL0, a
    mov a, _TH0
    addc a, #((TIMER0_REPROGRAM_VALUE >> 8) & 0xFF)
    mov _TH0, a
    setb _TR0
    ; Timer 0 is enabled again, every instruction above this line is counted as delay.
    ; Restore PSW, ACC
    pop psw
    pop a
    ; Turn on global interrupts.
    setb _EA
    __endasm;
}

// Interrupt handler
void isr_timer0(void) __interrupt(1)
{
    update_timer0();

    ticks++;
    if (sleep_ticks > 0)
        sleep_ticks--;
    sec_counter++;

}

SYSTICK_TIMER0_VALUE should be 52083.
TIMER0_REPROGRAM_VALUE is 13457 or 0x3491

But assembly below shows that 0xF3B7 is programmed into TIMER0.

    000019 74 B7            [12]  783   mov a, #(((0x10000 - (125000000 / 12 / 200)) + (12 * 4 / 12)) & 0xFF)
      00001B C2 8C            [12]  784     clr _TR0
                                    785 ;   Timer0 is disables, every instruction below this line is counted as delay
                                    786 ;   what the TIMER0 could advance while reprogramming.
      00001D 25 8A            [12]  787     add a, _TL0
      00001F F5 8A            [12]  788     mov _TL0, a
      000021 E5 8C            [12]  789     mov a, _TH0
      000023 34 F3            [12]  790     addc    a, #((((0x10000 - (125000000 / 12 / 200)) + (12 * 4 / 12)) >> 8) & 0xFF)

When replacing TIMER0_REPROGRAM_VALUE with (0x10000 - 52083 + TIMER0_REPROGRAM_TIMER_TICK_COUNT) the values are fine.

  000019 74 91            [12]  783     mov a, #((0x10000 - 52083 + (12 * 4 / 12)) & 0xFF)
      00001B C2 8C            [12]  784     clr _TR0
                                    785 ;   Timer0 is disables, every instruction below this line is counted as delay
                                    786 ;   what the TIMER0 could advance while reprogramming.
      00001D 25 8A            [12]  787     add a, _TL0
      00001F F5 8A            [12]  788     mov _TL0, a
      000021 E5 8C            [12]  789     mov a, _TH0
      000023 34 34            [12]  790     addc    a, #(((0x10000 - 52083 + (12 * 4 / 12)) >> 8) & 0xFF)

Do I something wrong?

Issue 2: When use any inline assembly, SDCC wants sdcc_atomic_exchange_rollback_start.

Why is this needed because I can't find any documentation and can I disable this?
Because I don't want extra code inside my interrupt function.

I added this to crtstart.asm as a workaround.

sdcc_atomic_exchange_rollback_start::
    ret

sdcc_atomic_exchange_rollback_end::
    ret

I am no problem moving inline-assembly update_timer0() to crtstart.asm.
But I am struggling how to use defines from C into asm-files.

I am using SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/r800/ds390/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02/f8 TD- 4.5.0 #15242 (Linux) from debian 13.

#189 6502 zero page overflow

2025-12-20T20:44:01.948000Z

status: pending --> closed-accepted

use of __reentrant in function pointer casting

2025-12-14T22:07:24.934000Z

I am reviewing some of the mos6502 disabled regression tests to see if they should be included.

in bug-2663 I found an interesting problem:
the test does some function pointer casting.
the test passes fine in the stack-auto configuration.

I tried to make the test work in the non stack-auto configuration by using the __reentrant keyword.

If i define a new type and cast to it everything works fine as expected.

static int cmp_eq (long arg1, long arg2) __reentrant

...

typedef int (*func)(long, long) __reentrant ;

...

ASSERT(((func)(string_binop1[0].op_func))(1, 1) == 0);

However, there is no place I could put the __reentrant keyword to make the explicit cast compile.

ASSERT(((int (*)(long, long))(string_binop1[0].op_func))(1, 1) == 0);

#208 Something goes wrong when building uCsim

2025-11-10T14:32:07.145000Z

Issue

make SILENT=no

in ucsim root directory.

#208 Something goes wrong when building uCsim

2025-11-10T11:41:25.136000Z

Description has changed:

Diff:

--- old
+++ new
@@ -1,5 +1,7 @@
+I was trying to build snapshots using the nativecrosstools branch.
+
 When sdcc fails to build, I can see the output from &#34;make&#34;, look at the command that resulted in the failure, and track it down from there.
-But what should I do when uCsim fails to build? All I see is something like ()
+But what should I do when uCsim fails to build? All I see is something like

 ~~~~
 CXX 51-port.o

Group: -->

Something goes wrong when building uCsim

2025-11-10T11:32:34.725000Z

When sdcc fails to build, I can see the output from "make", look at the command that resulted in the failure, and track it down from there.
But what should I do when uCsim fails to build? All I see is something like ()

CXX 51-port.o
In file included from /home/sdcc-builder/build/sdcc-build/orig/sdcc/sim/ucsim/src/sims/s51.src/port.cc:35:
/home/sdcc-builder/build/sdcc-build/orig/sdcc/sim/ucsim/src/sims/s51.src/regs51.h:35:17: error: expected unqualified-id before numeric constant
   35 | #define B       0xf0 /* B register (secondary accumulator) */
      |                 ^~~~

And while I can do a "make" in sdcc/sim/ucsim/src/sims/s51.src to try to build, I have no idea what command resulted in the failure, and "make --no-silent" also doesn't provide any extra output.

Something goes wrong when building uCsim

2025-11-10T11:32:34.725000Z

Ticket 208 has been modified: Something goes wrong when building uCsim
Edited By: Philipp Klaus Krause (spth)
Description updated:
--- description-old

+++ description-new

@@ -1,5 +1,7 @@

+I was trying to build snapshots using the nativecrosstools branch.
+
When sdcc fails to build, I can see the output from "make", look at the command that resulted in the failure, and track it down from there.
-But what should I do when uCsim fails to build? All I see is something like ()
+But what should I do when uCsim fails to build? All I see is something like

~~~~
CXX 51-port.o