I am using Teridian controller(71M6513) for metering solution. But Im running out of space in code area. I have features of size (approx. 80K).I am already using level 9 compiler optimisation. But still the code is not fitting in 64K. Now I enabled Extended linker LX51 and also Linker Code Packing and finally the code is fitting in 64K.
1.)Is it ok to use extended linker. 2.)What would be the side effects of using (LX51).
Please give details on where to use LX51 and BL51.
Urgent requirement. Thanks in Advance
Also please suggest me some other optimisation techniques from linker,compiler side.
have you tried to lower the compiler optimization level? that might reduce code size.
Have you made sure that you are always using the optimum data sizes?
bit variables when possible?
8-bit variable instead of 16-bit when possible?
16-bit instead of 32-bit?
Fixed-point integer evaluations instead of floating point.
No integer promotion, if you can get away with it?
Internal data for most used variables and less used variables that doesn't fit in the internal RAM moved into xdata?
As already mentioned, a higher optimization level doesn't always leads to smaller code. Some optimization steps increases code size to try to gain speed.
"1.)Is it ok to use extended linker."
Why would it not be OK?!
"2.)What would be the side effects of using (LX51)."
LX51 has, as the name suggests, more features than BL51; you can do things with LX51 that you couldn't do with BL51 - and, as you've seen, that can enable you to pack more code into a given space.
Nothing specifically to do with LX51, but the disadvantage of any extreme optimisation like this is that it makes bedugging - especially source level debugging - very much more difficult.
One other feature added by LX51 is the ability to put const data into XDATA space instead of CODE space. This is useful if you have a large (>64K) ROM and can map part of it to XDATA...
As Per says, it is important to ensure that your source code is optimal first before trying to squeeze it "after the event" with Linker tricks!
See: http://www.keil.com/support/man/docs/c51/c51_xc.htm And: www.8052.com/.../167378
"Have you made sure that you are always using the optimum data sizes?"
Not only data sizes - having your data in the correct memory space can make a significant difference!
Internal data for most used variables and less used variables that doesn't fit in the internal RAM moved into xdata? which means use the SMALL memory model.
Erik
Note that the Memory Model not only affects user-defined variables (which can be explicitly controlled anyhow) but also the space that the compiler uses when it has to "spill" parameters to RAM - and there is no other way to control that!
There are of course alternatives when it comes to memory model. Having the compiler automatically select a memory region, or explicitly tag the variables.
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.
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?
Hello All,
Thanks for all the inputs given till now. I will implement all of them and let u know the exact Numbers of saving each mehtod provided.
and let u micro know do you have micro's e-mail address I would like him to forward to me what you tell him.
The exact numbers probably won't be terribly meaningful as they will be very specific to your particular mess; however, it will probably be informative to know the general results - so thanks in advance for that...