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-
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.