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
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?