Deleting .OBJs versus "Build All"

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details	Message
Read-Only Author Drew Davis Posted 25-Aug-2005 23:59 GMT Toolset C51	Deleting .OBJs versus "Build All" Drew Davis 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 version 2: 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 version 1: 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 version 2: 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 This code happens to be from the 7.10 compiler, but we see the same thing with 7.50. Optimizations level 9 or 11, register coloring enabled. Load is bank switched, using LX51. Any clues as to what is going on? And is there a way to guarantee reliable results from the build short of manually cleaning up the last build every time?

Read-Only Author Stefan Duncanson Posted 26-Aug-2005 09:29 GMT Toolset C51	RE: Deleting .OBJs versus "Build All" Stefan Duncanson This seems quite strange. Have you tried looking at the .cod file? Could you post a bit more code showing the preamble to the existing snippets, preferably with source included?

Read-Only Author A.W. Neil Posted 26-Aug-2005 09:35 GMT Toolset C51	Register Colouring A.W. Neil "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?

Read-Only Author A.W. Neil Posted 26-Aug-2005 11:35 GMT Toolset C51	Odd build-time dependant effects... A.W. Neil 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...

Read-Only Author Drew Davis Posted 27-Aug-2005 03:07 GMT Toolset C51	RE: Odd build-time dependant effects... Drew Davis 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.

Read-Only Author Dan Henry Posted 27-Aug-2005 12:19 GMT Toolset C51	RE: Odd build-time dependant effects... Dan Henry "Which file holds register coloring information?" <project_name>.reg

Read-Only Author Jon Ward Posted 27-Aug-2005 15:30 GMT Toolset C51	RE: Odd build-time dependant effects... Jon Ward 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

Read-Only Author Al Bradford Posted 28-Aug-2005 00:56 GMT Toolset C51	RE: Odd build-time dependant effects... Al Bradford Jon; The point being, why does "Build All" not clear the *.REG file? Bradford

Read-Only Author Hans-Bernhard Broeker Posted 28-Aug-2005 17:05 GMT Toolset C51	RE: Odd build-time dependant effects... Hans-Bernhard Broeker 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?

Read-Only Author Drew Davis Posted 29-Aug-2005 22:34 GMT Toolset C51	RE: Odd build-time dependant effects... Drew Davis 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.

Read-Only Author Drew Davis Posted 23-Apr-2006 17:04 GMT Toolset C51	RE: Odd build-time dependant effects... Drew Davis 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.

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Deleting .OBJs versus "Build All"

Products

Development Tools

Hardware & Collateral

Downloads

Support

Contact

Important information