It seems that you frequently refer to things unrelated to 805x processors in this half of the site. If you want to advocate for large-scale MCU's, that would probably better fit in the CHAT section. The larger processor cores are quite nice. I've used several ARM's albeit CPU's and not MCU's. I do recognize that they offer advantages.

If you want to advocate for HLL's that are appropriate for those large-scale processors, the CHAT section welcomes such things. On this side, however, we have to focus on 805x. If you consider that core "lowly" then, I guess, you're welcome to your opinion, but, while ARM, MIPS, etc, topics are welcome on the CHAT side, let's confine our discussions to what belongs on THIS side.

HLL's for 805x are a valid topic for the 805x side of the site, so that's what we should discuss. I'm not interested at the moment in 805x C++ compilers, though I do believe there are a couple of them lying about here somewhere. C++ was designed for programming in the large, however, and that's not what one does with a core that has only 64KB of standard code space. "In the large" implies millions, and not just a few thousand, lines of code. Normally such tasks are approached by a team rather than an individual developer, and many decisions that affect coding have already been made by the time the coder becomes part of the team. The small developer using a small MCU, including the 805x, would have more direct input. In such a case, whether he uses a pencil and a datasheet, or compiler, or assembler, to construct his work product is entirely up to him. However, I stand by my statement that one who can't program his chosen MCU properly in ASM can't program it properly. Who has made the choice is not relevant. Yes, the manager often makes the choice and the subordinate developer has to "live" with that choice. Nevertheless, it's essential that the folks who design the code and the hardware environment fully understand the hardware environment. Compilers don't do that. They simply give expression to what the coder specifies. Unfortunately they seldom accommodate all features, so some>/> accommodation has to be provided in ASM, whether in the form of a callable function or included in a library of the coder's construction. I believe that fact alone sufficiently supports my assertion.

As for your remarks about the cellphone ... The problem is a typical management/software-generated problem. They started out with a system that didn't work well and later decided to mask the problem, since it couldn't be fixed, because of standardization, by adding features unhelpful to increasing quality. The system's bad, probably because of hardware and firmware issues, but it's permanently bad. Because it has been widely adopted, it will never be improved. I don't believe the pace of "progress" has much to do with, nor do the HLL's used to develop the system.

RE