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-
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.
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.
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.
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.
If you want optimum code out of Keil you don't have a choice but to deal with DPTR.
I asked for a demonstration of necessity of two things, and you answer with a vague claim regarding only one of them. why even bother? Is it really that hard to just admit that you're wrong?
I'll repeat: DPTR is not little-endian in any meaningful way. There's nothing you can do with DPH and DPL that would change in any way if their locations were exchanged --- or, for that matter, if they were moved to completely random locations each.