is there an optimization level that will do no, nada, none "code packing" and STILL overlay variables. it sems that after some release when opt lev 2 became required for variable overlay it is impossible to debug without having to do "strange things" to breakpoint one of 2 similar routines. Erik
The idea is that each Optimisation Level includes all optimisations from lower Levels - So Level 2 (Data Overlaying) should include Dead Code Elimination & Jump Negation (Level 1) plus Constant Folding, Simple Access Optimising, and Jump OPtimising (Level 0) http://www.keil.com/support/man/docs/c51/c51_optimize.htm Do any of those account for the "problems" you are seeing?
You might try selecting level 0 at the C source code which of course turns off overlay(Level 2). Then create SRC code for the your selected modules. Within the assembly code you can then make selected data segments OVERLAYABLE. Sounds like a lot of work. You still have level 0 invoked. Don't know how to eliminate that.
You might try selecting level 0 at the C source code which of course turns off overlay(Level 2). I am not making "hello world", I am making large projects, if I turn off any part of overlaying I am hosed. reinhard: what about an optimization level that does not do anything except overlaying as we had once in the past. Erik
Erik, I think you have to explain yourself better to justify your request. So: what, exactly, of the optimizations up to OP(2,speed), is so bad that you think you have to get rid of it? Your earlier reference to breakpointing only one instance of some (near-)duplicate code seems to suggest you must be using an OP level higher than 2 right now, possibly without being aware of it. Consistently refusing to use the IDE and having misplaced their manuals can do that to people. ;-> Well, at least by my book, none of the modifications affecting code size up to OP(2) can usefully be called "code packing", so I don't quite see why you're so upset about them. And I'm quite sure neither of them could possibly render breakpointing in duplicated code noticably harder. That should only start at level 4 (local CSE), and only become a major problem at level 8 (tail merging).
seems to suggest you must be using an OP level higher than 2 nope:
if "%MUSDEB%"=="0" goto cdeb c:\tools\keil\c51\bin\c51 %1.c LC CD OT (2) NOIP >..\trash\trashbin IF errorlevel=2 GOTO tell IF not "%SHOWAR%"=="1" goto noerr IF not errorlevel=1 GOTO noerr :tell c:\tools\keil\c51\bin\c51 %1.c LC CD OT (2) NOIP >>cmplst.txt goto noerr :cdeb c:\tools\keil\c51\bin\c51 %1.c LC CD OT (2) DB OE NOIP >..\trash\trashbin IF errorlevel=2 GOTO dtell IF not "%SHOWAR%"=="1" goto noerr IF not errorlevel=1 GOTO noerr :dtell c:\tools\keil\c51\bin\c51 %1.c LC CD OT (2) DB OE NOIP >>cmplst.txt :noerr
I really cannot believe that. OPTIMIZE(2) only performs very basic optimizations that do not affect debugging. Please send by email a small project that shows the behaviour that you are talking about. Reinhard
I will make a small demo next week, I am very busy this week. Erik
... waiting for small demo ...
... waiting for small demo ... sorry it took so long, I decided to post when I saw it and kinds forgot Erik
175 2 176 2 case J17S_XMUW: // E1 12 // waiting for serial interrupt 177 2 break; // this would be normal 178 2 179 2 case J17S_XMCW: // E1 12 waiting for serial interrupt after cksm xmit 180 2 break; // this would be normal 181 2 182 2 default: 183 2 jI1crash (); 184 2 break; 185 2 } ; SOURCE LINE # 176 ; SOURCE LINE # 177 ; SOURCE LINE # 179 ; SOURCE LINE # 180 ; SOURCE LINE # 182 005C ?C0026: ; SOURCE LINE # 183 005C 120000 R LCALL jI1crash ; SOURCE LINE # 184 ; SOURCE LINE # 185 ; SOURCE LINE # 189 005F ?C0017:
That example is really a little too terse to be useful. But let's see --- so you actually insist that the compiler should generate separate code for each of those two 'break' statements, so you can put a breakpoint on each of them separately? Looks like you're asking for wilful code bloat rather than absence of code packing. A case consisting of nothing but a 'break;' statement is arguably not even code, so 'code packing' doesn't really apply to what happens with it.
the issue here is that vyou can not set a breakpoint on a certain condition Erik
"the issue here is that you can not set a breakpoint on a certain condition" The problem is that you have no code on these conditions - and you can't set a breakpoint on nothing! The compiler isn't optimising-away your code; there is no code there to start with! Can't you use a data breakpoint?