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
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
The information in the global register coloring file is a result of several compiler/linker passes over the project and usually includes several different compiles of certain files. Failure to delete the .REG file could account for the problems you are seeing. Jon
Jon; The point being, why does "Build All" not clear the *.REG file? Bradford
The point being, why does "Build All" not clear the *.REG file? Probably because that would render them pointless. The real question would be: does register colouring really gain you enough that simply turning it off to work around this issue is a non-option?
I assume we're actually talking about the .orc file rather than a .reg file? http://www.keil.com/support/man/docs/uv3/uv3_b_filetypes.htm http://www.keil.com/support/docs/1774.htm This is one of those projects that's been growing for a couple of years. Every little bit of space savings helps, since there is a large installed base of hardware with a fixed memory size, and we're close to the limit. But it's not necessarily a project killer. Enabling register coloration seems to save perhaps 50 bytes out of 89K of code in this particular project. We'll see if turning off the optimization makes the problem go away. The deltas on the .lst files indicate a fair amount of unneeded register reloading when the .orc file is missing. "Unneeded", of course, in the opinion of the optimizer, which may be overly optimistic, or just plain misinformed by some error in our configuration. This would explain why some of the builds crash, as the optimizer removes code that really is needed to establish some parameter in a register. I'm not really clear on how to determine if this really is a compiler bug, or some sort of error in our bank configuration and assignments that somehow confuses the optimization.. Thanks for all the hints and suggestions so far.
Has there been any improvement on this problem in v8.00? It's still driving us nuts with 7.50. Everyone's adopted the habit of blowing away the object directory before a build; otherwise, there's about a 10% chance the executable is corrupt.