Hi, We are encountering unexpected behaviour following an increase in optimisation levels from 8 to 9. The problem we are seeing centres around an XDATA variable assignment (vt_safety_u = B0_SAFETY) which gets executed correctly under level 8 optimisation, but not under level 9. Using the disassembly view in the simulator, I can see that under level 8 optimisation (LARGE OPTIMIZE (SIZE))the line: vt_safety_u = B0_SAFETY; Generates the following assembly: B01:0xC019 00 NOP 386: vt_safety_u = B0_SAFETY; B01:0xC01A 90FB27 MOV DPTR,#vt_safety_u(0xFB27) B01:0xC01D 741D MOV A,#0x1D B01:0xC01F F0 MOVX @DPTR,A B01:0xC020 A3 INC DPTR B01:0xC021 744C MOV A,#0x4C B01:0xC023 F0 MOVX @DPTR,A Which appears correct, and results in the correct assignment taking place. However, the same line under level 9 (LARGE OPTIMIZE (9,SIZE)) results in the following trace: 386: vt_safety_u = B0_SAFETY; -107 B01:0xC01A 1224B7 LCALL B01:24B7 -106 B01:0x24B7 AA30 MOV R2,?B_MASK(0x30) -105 B01:0x24B9 E0 MOVX A,@DPTR -104 B01:0x24BA 09 INC R1 154: { -103 B01:0x24BB C3 CLR C -102 B01:0x24BC 13 RRC A : : : (Too long to post) : : -13 B01:0x00B3 020B5B LJMP C?CLDPTR(B01:0B5B) -12 C?CLDPTR: -12 B01:0x0B5B BB0106 CJNE R3,#0x01,B01:0B64 -11 B01:0x0B64 5002 JNC B01:0B68 -10 B01:0x0B66 E7 MOV A,@R1 -9 B01:0x0B67 22 RET -8 B01:0x24EA 6465 XRL A,#0x65 188: } -7 B01:0x24EC 8008 SJMP B01:24F6 -6 B01:0x24F6 120BA1 LCALL C?CSTPTR(B01:0BA1) -5 C?CSTPTR: -5 B01:0x0BA1 BB0106 CJNE R3,#0x01,B01:0BAA -4 B01:0x0BAA 5002 JNC B01:0BAE -3 B01:0x0BAC F7 MOV @R1,A -2 B01:0x0BAD 22 RET 195: } -1 B01:0x24F9 22 RET Following which, the variable assignment has not taken place, so it appears that the increase in optimisation has replaced 6 lines of assembly code that work with 107 lines that don't. In addition, the point at which the initial LCALL takes us to (B01:24B7) is midway through a segment that; a) Incorrectly assumes register initialisation (DPTR, R1, etc) has taken place. (e.g. DPTR is pointing at a unrelated global variable in line -105) b) Doesn't appear to have any relevance to a simple 2 byte assignment 'common block subroutine'. So it seems that the compiler is taking us to an incorrect location when the 'common block subroutine' optimisation is invoked. If true, my concern is that we're fortunate to have found this one, but there may well be other such instances that we're unaware of The toolset we're using is: C51 V7.50 A51 V7.10 BL51 V5.12 Can anyone throw any light on why this might be happening?