Extended Linker LX51

Thanks for all the information!

This code had been developed for past two years by many people and there is no consideration given for optimisation from coding level.The whole code is in a messy state.
Now Im given the responsibility of reducing the code size.I think it would be difficult to change the code now.So whatever has to be be done should be done only from Linker or compiler side only!

I have selected the following setting:
BL51 only
Memory Model :Large
Code ROM size:64K
Optimisation level:9,Common block sub-routine
Program Size: data=92.5 xdata=2590 code=62713
The hex file is not created with any other combination

With LX51:
Memory Model :Large
Code ROM size:64K
Optimisation level:11,Reuse common exit code

Program Size: data=92.5 xdata=2590 const=6574 code=50529

Given this scenario please let me know what could be the best possible option.
It is ok if I loose the speed of execution but i have to get the code size down.

Thanks in Advance

Thanks for all the information!

This code had been developed for past two years by many people and there is no consideration given for optimisation from coding level.The whole code is in a messy state.
Now Im given the responsibility of reducing the code size.I think it would be difficult to change the code now.So whatever has to be be done should be done only from Linker or compiler side only!

I have selected the following setting:
BL51 only
Memory Model :Large
Code ROM size:64K
Optimisation level:9,Common block sub-routine
Program Size: data=92.5 xdata=2590 code=62713
The hex file is not created with any other combination

With LX51:
Memory Model :Large
Code ROM size:64K
Optimisation level:11,Reuse common exit code

Program Size: data=92.5 xdata=2590 const=6574 code=50529

Given this scenario please let me know what could be the best possible option.
It is ok if I loose the speed of execution but i have to get the code size down.

Thanks in Advance

But notice that in many cases, you can do incrementative updates of variable declarations without touching the code logic. If you gain one byte for each access to a variable and that variable is accessed at 20 locations, you can quickly reclaim a lot of code space.

The whole code is in a messy state. Now Im given the responsibility of reducing the code size.I think it would be difficult to change the code now.
I feel for you, having to do something that is difficult. There is no way you can fix a mess without changing something.

Memory Model :Large

I would change to the small model and then add the XTATA qualifier to rarely accessed variables and add the IDATA qualifier to infrequently accessed variables till the memory spaces fall within acceptable limits. You will see a dramatic reduction in code size.

Erik

There is only so much that any optimiser can do - it is not magic; it cannot make a silk purse from a sow's ear!

It sounds like you have already applied the maximum compiler and linker optimisations - if that still leaves the code too big, then there is no other option than to re-examine the source code and fix any inherent inefficiencies!

"there is no consideration given for optimisation from coding level"

Then you are just going to have to start giving it some consideration!

Start by looking at the map file to see where the largest amounts of code are being used.

"I think it would be difficult to change the code now."

If it's too big, then you have no other choice - other than to change the hardware to provide more memory!

Have you checked that there isn't any redundant code left in that really shouldn't be there any more?

Is there any non-essential code that could be removed?