Disappointing optimisation...

That's strange - on all my fairly sizeable projects I see code size reductions of around the percentage Keil claim.

Do you have 'Favour size' selected?

"under Lx51 raising the optimsation levels from 9 to the 'new' levels of 10/11 actually increases the code size"

This has been my experience as well. There have been another couple of threads on this subject, the conclusion seemed to be that optimisation level 9 gives the smallest code.

"under Lx51 raising the optimsation levels from 9 to the 'new' levels of 10/11 actually increases the code size"

Me too! Sometimes there is little of no difference and sometimes the code size grows.

This was discussed at length a while back - even with some providing size comparison data:

http://www.keil.com/forum/docs/thread3346.asp

The results definitely do seem to depend upon the nature of your code...

Most of the optimization takes place in the compiler, so BL51 vs LX51 doesn't really say anything about the efficiency of the optimizer.

Did you turn on "linker code packing", under LX51?

Turning it on can sometimes reduce code size dramaticly.

"Most of the optimization takes place in the compiler, so BL51 vs LX51 doesn't really say anything about the efficiency of the optimizer.

Did you turn on "linker code packing", under LX51?

Turning it on can sometimes reduce code size dramaticly."

That's a bit contradictory, isn't it? Or don't you count linker optimisations as optimisations?

"Most of the optimization takes place in the compiler, so BL51 vs LX51 doesn't really say anything about the efficiency of the optimizer."

I don't care where the optimisation takes place- If using LX51 provides me with two extra levels of optimisation (and a bigger hole in my pocket after buying PK51), I don't think it's unreasonable to expect an overall reduction in code size, especially since, according to Keil:

"The LX51 has Linker Code Packing which reduces typically code size by 10..15% compared to the maximum optimizations that you can get with BL51"

I can only assume that our projects are atypical...

"I don't care where the optimisation takes place- If using LX51 provides me with two extra levels of optimisation (and a bigger hole in my pocket after buying PK51), I don't think it's unreasonable to expect an overall reduction in code size"

I agree, although as noted elsewhere the extra two optimisation levels are at best of dubious value. The big saving comes with the code packing jump/call optimisation.

"I can only assume that our projects are atypical..."

Maybe - do you have a large amount of constant data or something?

How many bytes TOTAL is your program?

Jon

Common area: 14553 (inc. 3345 bytes const data)
Bank 0: 62646
Bank1: 47812

I'm interested-how is this useful?

Linker code packing and AJMP/ACALL substitution is not very effective on small applications (that's why I asked the application size). In fact, there are a NUMBER of things that can reduce the effectiveness of the optimizer.

• If you already use ROM(COMPACT), AJMP/ACALL substitution will not gain much (since you're already doing this manually).

• Linker code packing searches for common code sequences and merges them into subroutines. The compiler also does this on a module basis. If there are few places this can be done globally, linker code packing doesn't have a big effect.

• No optimization can shrink constant data. So, if there's lots of it, don't expect too much.

Developers who get very little size reduction typically don't have much that can be optimized (lots of const data, tables, initialized variables, or just simply write optimal code to begin with).
It's kind of ironic, isn't it that the better programmer you are, the less the optimizer helps. The Irony comes from the fact that if you are not very good, you will probably not work on projects large enough to need optimization.

Erik

You should see a impact of at least 5% on a large application like yours. If you have not improvment, then you have most likely a configuration mistake of the toolchain.

Maybe the optimization level is hard coded in some header file and overrules the command line settings.

I came to this discussion kind of late. I was looking to understand why level 10 and 11 seem to make my gnerated .BINs larger. My projects are pretty big, getting just up to the 64K limit of teh classic 8051 architecture.

I have very carefully followed all optimization instructions. However, you said that I must have done somethign wrong if I do not see a 5%. Please hlep me find what I did wrong so I can get this benefit. I really need it in some of the bigger varients of my project.

"I was looking to understand why level 10 and 11 seem to make my gnerated .BINs larger"

If you are able to select levels 10 & 11, I think you must have a product that is entitled to support (unless your support period has expired). In that case, you might be better off contacting Keil support direct.

I seem to remember from a year or so back that there were some options that could "stick" when increasing the optimisation level; ie, when you thought you'd raised the whole project to level 10 or 11, there could be a few files left still with contradictory options.
You can check the listing files for this.

"I was looking to understand why level 10 and 11 seem to make my gnerated .BINs larger."

The general conclusion to the previous discussions of levels 10 and 11 was that they do in most (all?) cases give larger code than level 9. Keil advertised these extra optimisation levels for quite a long time before they appeared, so I guess they had to release them even though they didn't work.

"However, you said that I must have done somethign wrong if I do not see a 5%"

I think the 5% improvement comes from the switch from BL51 to LX51 with code packing enabled, but see the note from Jon Ward earlier in this thread. You don't need to select levels 10 or 11 for this to work.