This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Different .HEX code when Assembler SRC is selected C51 V6.10

Is there a bug? I have a well debugged and tested C program, that works fine with a normal compile. (Optimization Level 8, emphasis on code size ) It does not work correct when I enable the Assembler SRC generation and assemble the SRC files.

The bytes of code generated are exactly the same, but a comparison of the 2 resultant *.HEX files shows some differences. The differences occur near the beginning of the .hex file, and then the files are identical for the rest of the 3600+ bytes. Can anyone help?

  • As far as the Linker is concerned, the object created via SRC is an Assembler-generated object - not 'C'.

    There are some differences in the way the Linker treats Objects from the Assembler & the 'C' compiler; eg runtime support and optimisations.

    The C51 manual lists Optimisation level 8 as a Linker optimisation - so that could make the difference?

  • A follow-up. As I mentioned, I have two .c modules that get compiled. One (main.c) containing main() and functions, the other containing just functions (other.c)

    When I compile everything with .SRC generation, the program fails to pass all the paramaters correctly to at least one function contained in other.c. If I compile main.c with .SRC generation and other.c without .SRC generation, everything works correctly.

    The function failing has 4 paramaters being passed, the paramater that fails is the fourth.


  • What's the procedure prototype? The fourth parameter strikes me as significant because C51 passes up to three arguments in registers, while the fourth has to go into memory. Which memory depends on your memory model.

    Do the memory models match between main.c and other.c? If the caller assumes that extra arguments go into, say, xdata for the large model, while the callee assumes that arguments go into, say, data for the small model, you'd have a problem. Look at the assembler output for the C code that calls your function, and see where it puts that fourth param, and then look at the assembler code for the body of the routine and see where it expects it.


  • What types are the parameters?

    There were definitely some bugs with some of the 6.?? compiler versions when passing longs to functions compiled with SRC.

    I can't remember if I posted the details here, or just went straight to Keil support.
    If you have support, you should take this up direct with Keil.

  • "I can't remember if I posted the details here

    I just found it:
    http://www.keil.com/forum/docs/thread1188.asp

  • Thanks all for your help. I believe the problem is a compiler bug (V6.10) and not my program. For the curious, the function is

    void myFunc( unsigned char, unsigned char, unsigned char, unsigned int );
    The unsigned int is not retrieved correctly in myFunc when .SRC generation is enabled.

    To work around the problem I have had to leave .SRC generation OFF in general. If I want a function with inline assembler, I put it into a seperate code module, and enable .SRC generation for just that module. Then I do an extra testing step that makes sure the paramaters are being passed correctly. Then I write code.

    Is there a place on this site where Keil posts the known bugs in their current and past releases?

  • "Is there a place on this site where Keil posts the known bugs in their current and past releases?"

    Not as far as I know.

    Even the release notes don't tell you this sort of info. They've recently got a lot better, but the v6.xx ones were almost worthless. :-(