It's time to do some work on you're compiler. It generates the same code it did 20 years ago. I have to do tricks, instead of writing normal portable code, to get it to generate good code or just use inline assembler. This of course is nothing new, I've been telling you this for almost a decade. Keep in mind that all Intel processors are little endian and that you're compiler generates big endian code, why? You should at least offer a compiler switch to select endianness. Why don't you support C++ and MISRA? Oh and BTW IAR does all of the above TODAY! So clearly they haven't been standing still. (Notice who wrote the paper.)
www.eetimes.com/.../The-Inefficiency-of-C--Fact-or-Fiction-
"Is this forum only read by people that work for the company and are set in their ways against listening to customers?"
No.
The real answer is simple. YOU have a choice. If YOU don't like it, then YOU don't need to use it.
Personally I like the product and find it far better than the we attempt do it all attitude of the competition.
"Kiel is the only one that I know of ..."
"I will not thank Kiel or Arm for contining ..."
Looks like you get more than just a little bit confused when it comes to details.
That's a burry your head in the sand answer. Not everyone does. Some the decision is made for them before they even work for their company. Others are limited by budgets. And still others have to use the tools that the chip manufacture has partnered with.
"That's a burry your head in the sand answer."
Not at all. I've faced similar(ish) situations in the past (but stress not concerning Keil) and I always have the ultmiate choice; i.e., find another employer.
If your opinion is that the endian-ness is so critical in the 8051 architecture, then it suggests to me that you've gained little real experience in your 25+ years.
It is up to the developer to fully understand the tools, how they are used and (very importantly) how to use them effectively. If you can't effectively work around such a limitation then it says far more about your abilities that it does the Keil compiler.
It's really a matter of convenience and cost. Having to byte swap because of a lack of compiler switch means extra code space, slower execution and is a maintenance issue.
"Having to byte swap because of a lack of compiler switch means extra code space, slower execution and ..."
That depends entirely on the optimization capabilities of the compiler.
Do you really remember the level of optimization of the first Keil C compiler? I do; it was close to zero and very likely to produce faulty code. Compare that with the current release.
And you said at the very start:
"It generates the same code it did 20 years ago."
That is so not the case. I still have a copy of 3.05 (circa 1990) if anyone wants to see a comparison of produced code, but have long since thrown out all my copies if error reports I sent to Keil.
"... and is a maintenance issue."
Surely someone who writes portable code should be capable of looking after such issues as a matter of course.
If you're going to come out with such confrontational statements then you really should make sure you are factually correct.