From: SourceForge.net <no...@so...> - 2005-11-21 14:09:12
|
Bugs item #1362800, was opened at 2005-11-21 09:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R. Enzmann (xan-der) Assigned to: Nobody/Anonymous (nobody) Summary: Code bloat and FSR0 corruption for bit set/clear Initial Comment: 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 BSF INDF0, 7 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 |
From: SourceForge.net <no...@so...> - 2005-11-21 15:51:21
|
Bugs item #1362869, was opened at 2005-11-21 10:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362869&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R. Enzmann (xan-der) Assigned to: Nobody/Anonymous (nobody) Summary: Code bloat and FSR0 corruption for bit set/clear Initial Comment: 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 BSF INDF0, 7 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362869&group_id=599 |
From: SourceForge.net <no...@so...> - 2005-11-21 15:54:25
|
Bugs item #1362869, was opened at 2005-11-21 10:51 Message generated for change (Settings changed) made by xan-der You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362869&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Alexander R. Enzmann (xan-der) Assigned to: Nobody/Anonymous (nobody) Summary: Code bloat and FSR0 corruption for bit set/clear Initial Comment: 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 BSF INDF0, 7 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362869&group_id=599 |
From: SourceForge.net <no...@so...> - 2005-11-21 16:00:51
|
Bugs item #1362800, was opened at 2005-11-21 09:09 Message generated for change (Comment added) made by xan-der You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R. Enzmann (xan-der) Assigned to: Nobody/Anonymous (nobody) Summary: Code bloat and FSR0 corruption for bit set/clear Initial Comment: 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 BSF INDF0, 7 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 ---------------------------------------------------------------------- >Comment By: Alexander R. Enzmann (xan-der) Date: 2005-11-21 11:00 Message: Logged In: YES user_id=245280 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. Xander ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 |
From: SourceForge.net <no...@so...> - 2005-12-18 14:59:55
|
Bugs item #1362800, was opened at 2005-11-21 14:09 Message generated for change (Comment added) made by tecodev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target >Group: fixed >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Alexander R. Enzmann (xan-der) >Assigned to: Raphael Neider (tecodev) Summary: Code bloat and FSR0 corruption for bit set/clear Initial Comment: 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 BSF INDF0, 7 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 ---------------------------------------------------------------------- >Comment By: Raphael Neider (tecodev) Date: 2005-12-18 14:59 Message: Logged In: YES user_id=1115835 (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 ---------------------------------------------------------------------- Comment By: Alexander R. Enzmann (xan-der) Date: 2005-11-21 16:00 Message: Logged In: YES user_id=245280 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. Xander ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 |
From: SourceForge.net <no...@so...> - 2005-12-19 14:25:29
|
Bugs item #1362800, was opened at 2005-11-21 09:09 Message generated for change (Comment added) made by xan-der You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target Group: fixed >Status: Open Resolution: Fixed Priority: 5 Submitted By: Alexander R. Enzmann (xan-der) Assigned to: Raphael Neider (tecodev) Summary: Code bloat and FSR0 corruption for bit set/clear Initial Comment: 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 BSF INDF0, 7 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 ---------------------------------------------------------------------- >Comment By: Alexander R. Enzmann (xan-der) Date: 2005-12-19 09:25 Message: Logged In: YES user_id=245280 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. Thanks! Xander ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2005-12-18 09:59 Message: Logged In: YES user_id=1115835 (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 ---------------------------------------------------------------------- Comment By: Alexander R. Enzmann (xan-der) Date: 2005-11-21 11:00 Message: Logged In: YES user_id=245280 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. Xander ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 |
From: SourceForge.net <no...@so...> - 2006-02-08 18:42:51
|
Bugs item #1362800, was opened at 2005-11-21 14:09 Message generated for change (Settings changed) made by tecodev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target Group: fixed >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Alexander R. Enzmann (xan-der) Assigned to: Raphael Neider (tecodev) Summary: Code bloat and FSR0 corruption for bit set/clear Initial Comment: 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 BSF INDF0, 7 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 ---------------------------------------------------------------------- Comment By: Alexander R. Enzmann (xan-der) Date: 2005-12-19 14:25 Message: Logged In: YES user_id=245280 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. Thanks! Xander ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2005-12-18 14:59 Message: Logged In: YES user_id=1115835 (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 ---------------------------------------------------------------------- Comment By: Alexander R. Enzmann (xan-der) Date: 2005-11-21 16:00 Message: Logged In: YES user_id=245280 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. Xander ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1362800&group_id=599 |