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-
"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?
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.
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.
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.
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.
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?
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.
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.
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.
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.
There are 16-bit registers in the 8051 and its derivatives and since all registers are memory mapped endianness is CRITICAL.
Pardon the French, but that's complete and utter male bovine manure.
Face it: none of the ways an 8051's few 16-bit registers (PC, DPTR, T0, T1) can be used has any practical relevance to endianness. Only one of them (DPTR) even has its two bytes stored in adjacent SFR locations to allow so much as speaking of its endianness! And since SFR space is direct addressing only, if the locations of DPL and DPH were exchanged, no C code would even notice!
The 8051 has no more than 3 opcodes that as much as touch more than a single byte i pointer-addressable memory space: JSR, RET and RETI. In the end the only way one could even determine an endianness to the 8051 is by looking at the storage format of return addresses on the stack. Which is far from critical.
"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.
"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.
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.
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.
View all questions in Keil forum