#1022 Code bloat and FSR0 corruption for bit set/clear


SDCC : pic16/pic14 2.5.4 #1152 (Nov 20 2005) (MSVC)

Between build 1121 and 1152 there has been a change
that causes quite a bit of added code when
manipulating bits in SFR's. For example, this code:
EECON1bits.EEPGD = 1;

Used to compile to this:
BSF _EECON1bits, 7

Now it compiles to this:
LFSR 0x00, _EECON1bits

SFRs do not need the extra indirection. This is a
big hit for any code that regularly manipulates bits
in SFRs.

There also seems to be an unfortunate trashing of
FSR0 (from LFSR 0x00, ...), which does not get saved
on the stack when a function is entered (like FSR1
and FSR2). This presents a added burden when mixing
asm and C code in a routine.



  • xander

    xander - 2005-11-21

    Logged In: YES

    After much trial and error debugging my code, I've found a
    situation where the code generated by 1152 is bad. When
    self programming code memory, there's an unlock/start
    write sequence that goes like this:
    movlw 0x55
    movwf _EECON2
    movlw 0xaa
    movwf _EECON2
    bsf _EECON1, 1

    If I write it in SDCC like the following:
    EECON2 = 0x55;
    EECON2 = 0xAA;
    EECON1bits.WR = 1;

    It will fail. Setting the bit on EECON1 has to happen
    right after EECON2 has 0xaa assigned to it. Instead, SDCC
    produces this code when setting the bit:

    ; .line 931; programmer.c EECON1bits.WR =
    1; // Start erase (CPU stall)
    LFSR 0x00, _EECON1bits
    BSF INDF0, 1

    The result is that the write (or erase, as the case may
    be) doesn't occur. The extra statement before the bsf
    causes the failure.


  • Raphael Neider

    Raphael Neider - 2005-12-18

    Logged In: YES

    (1) Fixed in src/pic16/gen.c 1.104, SDCC #1187.

    Please check and report any newly introduced bugs/not
    covered cases, thanks.

    (2) What would be the benefit of saving FSR0? FSR0 is
    considered to be a local, caller-saved "scratch" SFR, whose
    contents is usually more easily restored than
    saving/restoring it.
    Could you make your second problem more clear?


  • Raphael Neider

    Raphael Neider - 2005-12-18
    • milestone: --> fixed
    • assigned_to: nobody --> tecodev
    • status: open --> pending-fixed
  • xander

    xander - 2005-12-19

    Logged In: YES

    Appears fixed in 1187. Code size in my application went
    down close to 10%. Errors in bet set/clear for memory
    unlock sequence appear fixed.



  • xander

    xander - 2005-12-19
    • status: pending-fixed --> open-fixed
  • Raphael Neider

    Raphael Neider - 2006-02-08
    • status: open-fixed --> closed-fixed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks