Oleg Endo - 2026-04-04

Where one can see the redundancy of the first instruction,
mov a,_ACC

This was one of the things which I tried to address in issue 466,

https://sourceforge.net/p/sdcc/patches/466/attachment/0009-add-isSpecialRegister-peephole-condition-function-al.patch

My patched-up SDCC produces the following:

__sfr __at(0xE0) ACC;
__sfr __at(0x82) DPL;
__sfr __at(0x90) OTHER_SFR;

void test_10 (void)
{
  if (ACC & 0x01) ACC = 0;
  if (DPL & 0x01)  DPL = 0;
  if (OTHER_SFR & 0x01) OTHER_SFR = 0;
 }

_test_10:
;   if (ACC & 0x01) ACC = 0;
;   if (DPL & 0x01)  DPL = 0;
    mov a,_DPL
;   if (OTHER_SFR & 0x01) OTHER_SFR = 0;
    mov a,_OTHER_SFR
    jnb acc.0,00107$
    mov _OTHER_SFR,#0x00

Since ACC and DPL/DPH/DPTR are standard registers that are used by the compiler for usual code generation it realizes that the results are not used and omits all of the code (except for a the last dangling mov a,_DPL)

This might be a little unexpected if some code relies on those SFRs being treated effectively like volatile variables.

However, for other "unknown" SFRs it will preserve the operations.

For the 2nd case, I'm getting the following (using svn r 16432)

__sfr __at(0x80) P0;

void main(void) { }

void isr(void) __interrupt(0) {if (P0 & 0x4) P0 = 1;}


_isr:
    push    acc
    mov a,_P0
    jnb acc.2,00103$
    mov _P0,#0x01
00103$:
    pop acc
    reti

This seems to be the main issue of this request. The compiler doesn't know that an SFR is also bit-addressable. If the address of the SFR is known at compile time, it could certainly deduce that.

    mov a,_P0
    jnb acc.2,00103$

This might be actually implemented as a peephole optimization. In addition to my proposed isSpecialRegister peephole support function it would also require another one to check if a a special register is also bit addressable, by e.g. checking for this:

f the source code is detected to be bit addressing a SFR with an address of the form 0b1XXX'X000.