Time to update your compiler

Keep in mind that the 8051 is an 8-bit (ie, single byte) processor - so "endian-ness" has no meaning to the processor...

evidently the OP prefer Picasso to DaVinci

There is, today, a tendency to abstract everything so far that the processor becomes irrelevant.

While that, indeed, may be a reasonable approach for very powerful processors (see PS) it will never be so for the small 8 bitters.

Erik

PS do you realize that much of the software (written before 'abstraction') that ran on your old 10MHz XA actually ran faster than the 'abstracted' one running on your 2GHz machine.

... there is no such thing as portable code

If anyone can show a "labor free" porting from e.g. a 68xx to a '51 I would love to hear about it.

Erik

You couldn't be more wrong. There are 16-bit registers in the 8051 and its derivatives and since all registers are memory mapped endianness is CRITICAL.

I have one common header file that I use across 8, 16, 32 and 64 bit processors. My 8051 designs often interact with Windows machines using the same code libraries (AKA portable code). Using each compiler's standard defines with ifdef's some keywords are replaced but the code is the same.

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"

Erik

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.

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.

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.