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