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-
Oh and BTW IAR does all of the above TODAY!
Use IAR, then. It's called competition. If enough people switch from Keil to IAR, maybe Keil will scratch their heads and think what they can do to win customers back. If people don't switch, then maybe they simply don't need a better compiler from Keil?
So I'm suppose to pay for annual support (for decades) that provides no updates to the compiler (they do add parts and make changes to the IDE)? And then pay for another compiler on top of that because compeditors actually do development work? Therein lies the problem, both have extended the C language and I'd have to rewrite my legacy code instead of being able to reuse it. So because I've been using Keil for some 25 years I now have to go elsewhere to get a modern tool? I want a tool that can detect more problems at complile time (C++ type checking is a step toward Lint, MISRA is also useful as a methodology). Plus Keil (Arm) are in bed with vendors who's chips I use and switching compilers for lack of support would put me further out on the support limb. I just want a tool developer to actually develope their tool instead of charging maintance and not fix bugs or move forward.
I just want a tool developer to actually develope their tool instead of charging maintance and not fix bugs or move forward. we can discuss, ad nausem, which features are fitting for a compiler for an 8 bit system, but WHAT BUGS
Erik
Plus Keil (Arm) are in bed with vendors who's chips I use and switching compilers for lack of support would put me further out on the support limb
you seem to be a "C is C" guy, what does it matter which compiler a chip manufacturer is "in bed with"
PS re tool vendors: I know of no instance where the competitor(s) do(es) not have (a) feature(s) that I would prefer to my chosen (to me most attractiven) tool
It's been many years now since I reported a bug that wasn't fixed so I've forgotten it now because I designed around it. They did give me a free year of support to no avail, they didn't fix the bug in either year.
Ah the point here is that the vendor got in bed with Keil and corrupted their hardware to be compatible with the compiler. Meaning that all the standard 8051 registers were little endian while all the proprietary extended architecture registers were big endian, what a nightmare to write code for.
"Ah the point here is that the vendor got in bed with Keil and corrupted their hardware to be compatible with the compiler. Meaning that all the standard 8051 registers were little endian while all the proprietary extended architecture registers were big endian, what a nightmare to write code for."
Your text clearly indicates that you don't know the subject and is based on factless false assumptions.
"Your text clearly indicates that you don't know the subject and is based on factless false assumptions."
While your ignorant comment is ambiguous enough to have no meaning at all, even the FAEs of the manufacturer (who shall remain nameless) recognized what I pointed out to them. If a Keil person wants clarification then I would be more than happy to provide them the facts since I've already done so in the past.
And I can without doubt say that you do not know the 8051 as well as myself since you are not John Wharton. I have done countless projects with the 8051 family over more than 25 years.
Meaning that all the standard 8051 registers were little endian
No, they aren't, and never were. None of the standard 8051 as much as has an endianness to speak of.
I have done countless projects with the 8051 family over more than 25 years.
And you appear to be on a mission to prove that despite all conventional wisdom to the contrary, a person can actually be wrong about a fundamental aspect of their field of work for all those 25 years --- and proud of it.
DPTR, DPH, DPL.... care to explain their little endian addresses? How about the fact that Intel only does little endian processors? Or that the 8051 evolved from the 8048, another little endian processor.
Can you explain how Keil is and has been the only compiler vendor for the 8051 that has tried to make it little endian inspite of its own architecture and history while everyone else has implemented it correctly?
It is a little 8 Bit CPU it is not going to Run Full C++. C++ is Not C running it it's error checks may or may not make sense. If you want MISRA and LINT then use LINT, what is the problem. How much can a 25 year old Compiler for a 30 year old CPU change? And does it help? Hi-tech changed their PIC Compiler I do not think they did anybody any favors. If Keil changes it enough Your legacy code may not work any more.
DPTR, DPH, DPL.... care to explain their little endian addresses?
Why would I? I've already stated there is no such thing.
DPTR doesn't even have an address, and the addresses of DPH and DPL could be exchanged without any consequence to code that would be worth mentioning. No pointer can point to either of them, so it doesn't matter if you have to advance by +1 or -1 to point to the other.
How about the fact that Intel only does little endian processors?
That doesn't apply here, because the 8051 is, for all practical intents and purposes, a no-endianness processor.
I'm not asking for full C++ (does anybody actually provide all of that and only that correctly? no), read the paper in the post, they're right on target.
Not Feeling like Registering Right Now. But the article is for ARM not 8052. The 8052 is Hostile to C let alone C++. It has been talked about for years, does IAR have a one? Ceibo had one years back, those that used it said it was more a science project. Not a lot of room for the actual program.
Remember that C and C++ have diverged. There are some subtle differences that have crept in over the years. There is not C/C++ anymore.
As far as endianess like may other things the decision was made long ago and for good or bad it is not changing now. Maybe the origional programmer was a Motorola guy. Or the code they started with was that way. Maybe it made the compiler code easier. But, now it is what it is. And I do not think the business case would say investing in a big / little option would have a big return on investment. Be thankful that ARM still supports the compiler and did not end of life it. Or thank Keil for making them keep it going.
While the article uses IAR's ARM C/C++ complier as an example it is a general purpose article that points out that C++ has great benefits over C and when used appropriately adds no overhead.
I've found the 8051 C friendly, not quite to the level of the pdp like it was originally intended but good enough with some minor language extensions.
Kiel is the only one that I know of that seperates C from C++ at this point.
My point is why pay for maintance if they don't do that? The business case is that people are paying for bug fixes and new features and since the 8051 is the most used processor on the planet every year it has quite the customer base. I will not thank Kiel or Arm for contining with a product that brings money in every year which they do not provide support like other vendors do. This complier is not chiseled in stone, if they want they can add features to it as I've pointed out.
I just came back from a show where the Keil people requested that I post this to their forums because they wanted their management to read what their customers want and what their compeditors offer (it always has more weight from the outside than within).
Is this forum only read by people that work for the company and are set in their ways against listening to customers?
"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.
You really need to get help. Your paranoia is getting way out of hand.
My point is why pay for maintance
Oh, for Pete's sake. So don't pay and do us all a favour and get lost, why don't you?
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.
Byte suddenly being little or big-endian? Impossible.
The bits in a byte are just that - bits. Don't spend too much time figuring out the bit addressing, thinking that would have anything to do with the little/big endian issue.
Almost all processors defines bytes/words/... to have bit 0 as least significant bit. Creating a bit-addressing instruction, it would be very stupid to suddenly number the bits: 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 ... just to make a statement about big/little order.
But if you do want to have fun - look at some Freescale processors where the bits are numbered in reverse order. Truly magnificent to read a schematic and figure out that A30 is not a really "big" address line but one of the smallest. These bit issues probably resulted from some people stupidly trying to extrapolate word endianness into the naming of individual bits too.
I don't think I have ever seen a little-endian processor numbering bit 0 as the most significant bit. But big-endian processors sometimes names the most significant bit 0, and sometimes the least significant bit.
Hence, even if you do try to use the bit endianness in the discussion, the use of bit0 as least significant can't be used as any proof since it is used by bost little-endian and big-endian processors.
Next thing. If you have a 3-byte instruction, one byte op-code and two byte address, you shouldn't try to merge the opcode with the first byte of the address and imply big or little endian. That is just an ugly extrapolation.
View all questions in Keil forum