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-
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.
Way back when, probably before your time, there were two popular processor companies, Intel (little endian) and Motorola (big endian).
As for the 8051, if you were to look at the SFR registers it is clear that the 8051 is little endian (DPL is the address lower than DPH). Also look at bit address space (little endian again) and the internal and external stack spaces and how they're used. There are companies that have added extra memory pointers and even made them do auto-increment (again all little endian). When an application from Keil communicates with a WinTel PC it has to byte swap data structure elements that are more than one byte so they can be understood. And then there is USB and TCP/IP. All support that Keil is big endian while the 8051 is little endian just try to load DPTR backwards and see how well your code works.
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.
All support that Keil is big endian while the 8051 is little endian just try to load DPTR backwards and see how well your code works.
I might, once you've demonstrated that any C program ever
a) needs to load the DPTR itself, rather than let the compiler handle it, and
b) needs to do so in any way that involves the actual addresses of DPL and DPH.
Without b), there is no endianness effect, much less a "CRITICAL" one, because exchanging those addresses would not change the behaviour of the program in any way.
"Why would I? I've already stated there is no such thing."
Well Intel disagrees with you and their opinion is the only one that really matters.
All the registers are little endian, 1-bit, 8-bit, 16-bit (capture 2, timer/counter 0-2, DPTR) as well as all the fields within them. Only with a very few exceptions (the one I'm not mentioning the mfgr for specifically) do other manufacturers that add on to the original specification deviate from little endian, just read the data books. Even the one exception forces little endian alignment (but not ordering) for some things, how bizare.
The subroutine calls push LSB then MSB (that's little endian). I know, you're going to say that the 16-bit constant instructions are big endian, think again, the first byte of the instruction (the actual opcode) or the little endian part is followed by a big endian then a little endian which is how a little endian machine works (little endian at lower address).
So do you work for Keil and are the person that got it backwards in the first place and are now trying to defend that mistake?
Care giving a citation of an actual statement by Intel, about the MCS51 architecture, that backs up your claim?
All the registers are little endian
Nonsense. The vast majority of 8051 registers are single bytes. Endianness can't even be defined for those. So much for "all registers".
capture 2
No such thing on an actual 8051.
timer/counter 0-2
Care explaining how a 16-bit timer stored in SFR addresses 8A and 8C (with a rather unrelated other SFR in between, at 8B) is little endian in any "CRITICAL" way?
Oh, and there's no such thing as timer/counter 2 in an actual 8051.
just read the data books
Which of the roughly 500 different data books describing 8051 variants in particular?
Oh, right, you wont't/can't divulge the particulars. Sure. And just because you're paranoid doesn't mean THEY are NOT out to get you.
forces little endian alignment
Nobody can force that, because that's a meaningless combination of words.
A couple posts before you were trying to discredit me as being too young to know what big-/little endian is about, and now I'm supposed to be none less than the Evil Mastermind that ruined your world? Could you make up your mind?
Did it ever occur to you that if all the world disagrees with you, this might be because you're plain and simply wrong?
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?
If you want optimum code out of Keil you don't have a choice but to deal with DPTR. That is my point as to the fact that in 20 years they haven't worked on the compiler. I have compared the output of code from the 80's and now and it's the same. As for DPL and DPH, when writing tight code it can save you code space and clocks to load one of them directly instead of DPTR.
"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.