We're still getting some odd results from the C51 toolchain from time to time. We get different builds if we manually delete all .OBJs than if we tell uVision to "build all". You'd think that would replace all the .OBJs. We get different code generated when the load is rebuilt with the two methods. And in the "build all" case, the loads often do not run correctly, while the manually deleted version does. I can't imagine why there's a difference in the two cases; you'd think "build all" would rebuild everything, and start just by deleting the existing .obj. A couple of examples of the same section of code from the two different build methods: version 1:
R MOV DPTR,#entry MOV A,R6 MOVX @DPTR,A INC DPTR MOV A,R7 MOVX @DPTR,A ; SOURCE LINE # 189 ; SOURCE LINE # 191 R MOV queues,#08H ; SOURCE LINE # 192 R MOV queues+01H,#08H ; SOURCE LINE # 194 R MOV DPTR,#entry MOVX A,@DPTR MOV R6,A INC DPTR MOVX A,@DPTR ADD A,#05H MOV DPL,A
MOV R3,AR7 MOV R2,AR6 ; SOURCE LINE # 189 ; SOURCE LINE # 191 R MOV queues,#08H ; SOURCE LINE # 192 R MOV queues+01H,#08H ; SOURCE LINE # 194 MOV A,R3 ADD A,#05H MOV DPL,A
R MOV DPTR,#link MOV A,R7 MOVX @DPTR,A INC DPTR MOV A,R4 MOVX @DPTR,A INC DPTR MOV A,R5 MOVX @DPTR,A ; SOURCE LINE # 552
R MOV DPTR,#igmp MOV A,R4 MOVX @DPTR,A INC DPTR MOV A,R5 MOVX @DPTR,A ;---- Variable 'link' assigned to Register 'R3' ---- MOV R3,AR7
"We get different builds if we manually delete all .OBJs than if we tell uVision to 'build all' ... register coloring enabled" This has caused me similar problems before. IIRC, the "register colouring" file was not deleted by 'Build All' - so it could affect the results. So, when you say, "delete all .OBJs" do you just delete *.obj, or do you clear the entire "objects" folder - which would include the "register colouring" file?
Are you using any/all of __DATE__, __TIME__, __FILE__, __LINE__, etc in your code? I have occasionally seen bizarre side-effects as a result of these; eg When the time goes from 9:59:59 to 10:00:00, the length of the string changes. Using __LINE__, even just adding/removing a comment can affect the generated code, as the source line numbers will change! Strings are generally stored in CODE space, so these kinds of things can affect the usage of code space... This may be entirely irrelevant to your situation, but might be something to think about if all else fails...
Thanks for the suggestions. We clear out the old objects with a "del *.obj", so anything else hiding in that directory will still be around. Which file holds register coloring information? We do have a __DATE__ __TIME__ in one module which, well, displays the date and time of the build on a CLI over a UART. That file is marked as "always build" in uVision. Most of the differences look very much like optimization to me. Some differences just omit repeated loading of R3 with 1 for a generic pointer to xdata, for example, or have some DPTR accesses where a temp appears to spill out of the register set. The most disturbing thing is that the loads are functionally different. That is, we get bugs or the code hangs with build all, but if we delete the obj's and rebuild, it works fine. Same source.
"Which file holds register coloring information?" <project_name>.reg
View all questions in Keil forum