differences between compiler/linker versions

Hi,
I have inherited a project, with no handover, and little documentation, so am in a spot of bother, as I haven't done embedded work for 15 years! My question is a bit vague, but is as specific as I can make it at present.

Question - does moving to a newer compiler/linker version necessitate any reworking of the source code?

Background - I have a uVision project with a 80C51 target. I have the old obj, hex, compiler/linker output files, from which I can verify that I am using the same build parameters.

The old working hex is 87477 bytes, and was built from:

C51 COMPILER V7.50
MACRO ASSEMBLER A51 V7.10
BL51 BANKED LINKER/LOCATER V5.12

My recompiled hex is 87619 bytes, and was built from:

C51 COMPILER V7.05
MACRO ASSEMBLER A51 V7.04a
BL51 BANKED LINKER/LOCATER V5.03

My newly built version runs, and identifies itself as the correct version, on startup, but the serial comms is not functioning as expected, and the chip does not identify itself correctly to the Windows monitor application. My obj and hex differ slightly in size.
Needless to say, I don't have the older compiler.

Further info. Extract from previous working build

C51 COMPILER V7.05, COMPILATION OF MODULE MAIN
OBJECT MODULE PLACED IN MAIN.OBJ
COMPILER INVOKED BY: C:\Keil\C51\BIN\C51.EXE MAIN.C LARGE BROWSE ORDER DEBUG OBJECTEXTEND

MODULE INFORMATION:   STATIC OVERLAYABLE
   CODE SIZE        =   1088    ----
   CONSTANT SIZE    =   ----    ----
   XDATA SIZE       =   ----     129
   PDATA SIZE       =   ----    ----
   DATA SIZE        =   ----    ----
   IDATA SIZE       =   ----    ----
   BIT SIZE         =   ----    ----
END OF MODULE INFORMATION.

----------------------------------------------------------

MACRO ASSEMBLER A51 V7.04a
OBJECT MODULE PLACED IN hw_mi.OBJ
ASSEMBLER INVOKED BY: C:\Keil\C51\BIN\A51.EXE hw_mi.src PR(.\hw_mi.ls1) EP DEBUG

LOC  OBJ            LINE     SOURCE

                       1     ; .\hw_mi.SRC generated from: hw_mi.c
                       2     ; COMPILER INVOKED BY:
                       3     ;        C:\Keil\C51\BIN\C51.EXE hw_mi.c LARGE BROWSE ORDER DEBUG OBJECTEXTEND SRC(.\hw_mi.SRC)

----------------------------------------------------------

BL51 BANKED LINKER/LOCATER V5.03, INVOKED BY:
C:\KEIL\C51\BIN\BL51.EXE VAR_DEF.obj, com.obj, disp_op.obj, entry.obj, hw_mi.obj, INIT.obj, MAIN.obj, MIDNIGHT.obj, OP_D
>> ISW.obj, OP_FILLW.obj, OP_LOADW.obj, OP_MIX.obj, op_prep.obj, op_run.obj, OP_TRANS.obj, OP_WAIT.obj, UTILS.obj TO MI3
>> 21 RAMSIZE (256) XDATA (0X0100-0XFFFF)
MEMORY MODEL: LARGE WITH FLOATING POINT ARITHMETIC
.
Program Size: data=216.0 xdata=60178 code=30433
LINK/LOCATE RUN COMPLETE.  2 WARNING(S),  0 ERROR(S)

Extract from my build

C51 COMPILER V7.50, COMPILATION OF MODULE MAIN
OBJECT MODULE PLACED IN MAIN.OBJ
COMPILER INVOKED BY: C:\Keil\C51\BIN\C51.EXE MAIN.C LARGE BROWSE ORDER DEBUG OBJECTEXTEND

MODULE INFORMATION:   STATIC OVERLAYABLE
   CODE SIZE        =   1087    ----
   CONSTANT SIZE    =   ----    ----
   XDATA SIZE       =   ----     129
   PDATA SIZE       =   ----    ----
   DATA SIZE        =   ----    ----
   IDATA SIZE       =   ----    ----
   BIT SIZE         =   ----    ----
END OF MODULE INFORMATION.

-----------------------------------------------------------

MACRO ASSEMBLER A51 V7.10
OBJECT MODULE PLACED IN hw_mi.OBJ
ASSEMBLER INVOKED BY: C:\Keil\C51\BIN\A51.EXE hw_mi.src PR(.\hw_mi.ls1) EP DEBUG

LOC  OBJ            LINE     SOURCE

                       1     ; .\hw_mi.SRC generated from: hw_mi.c
                       2     ; COMPILER INVOKED BY:
                       3     ;        C:\Keil\C51\BIN\C51.EXE hw_mi.c LARGE BROWSE ORDER DEBUG OBJECTEXTEND SRC(.\hw_mi.SRC)

----------------------------------------------------------

BL51 BANKED LINKER/LOCATER V5.12, INVOKED BY:
C:\KEIL\C51\BIN\BL51.EXE VAR_DEF.obj, com.obj, disp_op.obj, entry.obj, hw_mi.obj, INIT.obj, MAIN.obj, MIDNIGHT.obj, OP_D
>> ISW.obj, OP_FILLW.obj, OP_LOADW.obj, OP_MIX.obj, op_prep.obj, op_run.obj, OP_TRANS.obj, OP_WAIT.obj, UTILS.obj TO MI3
>> 21 RAMSIZE (256) XDATA (0X0100-0XFFFF)
MEMORY MODEL: LARGE WITH FLOATING POINT ARITHMETIC
.
Program Size: data=216.0 xdata=60178 code=30491
LINK/LOCATE RUN COMPLETE.  2 WARNING(S),  0 ERROR(S)

Many thanks,
Nigel Frost

 RE: differences between compiler/linker versions

This issue might be related to a different optimization level / toolchain improvement that removed some code that was supposed to remain - maybe a variable that was not declared "volatile"...?
Can you debug the serial communication handling code?

 RE: differences between compiler/linker versions

Thanks for your reply. Following on from your comments, I have managed to get hold of the exact earlier version of the tool chain from the supplier, and I now have a working controller! See also my reply to Hans-Bernhard.

 RE: differences between compiler/linker versions

Question - does moving to a newer compiler/linker version necessitate any reworking of the source code?

At the level of generality you ask the question, the answer can only be: it may.

Default states of compiler options, particularly optimization settings, may change --- which is why it's not so terribly advisable to run the compiler at default settings, like you appear to. Or maybe some optimization improved sufficiently for code that only ever worked by happenstance rather than by design to finally break noticeably.

This does beg one question, though: what's keeping you from using the same version of the tools that had been used until now? There also seems to be a discrepancy between your statements. First you say the old file was built with C51 7.50, but then you say your new build was made with it.

Generally, looking at screen output of the compiler(s) doesn't really tell you (nor us) all that much. What you really should be looking at are the list, map and hex files to isolate and eliminate changes to sizes of individual functions, changes to the size of variables, and finally the code itself, one by one.

 RE: differences between compiler/linker versions

Thanks, this is very helpful.
Firstly, you are quite right to spot that I have the compiler versions the wrong way round in my original question.
At the time of asking, I only had the later version of the toolchain, and the list, map, obj and hex files from the previous build. This is a job for a small private firm, and they have no source control, etc.
Following on from both replies, I realised that I had to get hold of the earlier tool chain version, as a starting point. I managed to get this from the Keil supplier, and I now have a working controller.
I shall later follow your suggestion, and compare output files between Keil versions, and find out what code is causing the discrepancy, as this does suggest a vulnerability in the code.
Thanks to both of you, I consider my question answered!