However, I find that people who write and use "lousy" assembler are just as likely to generate "lousy" 'C'-code. Writing "lousy" code of any sort is a matter of habit and not a matter of ability. IMHO, the things that really matter in MCU programming almost always require they be written in ASM anyway.

From where I sit, it looks to me as though there are programmers who generate "lousy" code, and programmers who don't. While it's true that more people know how to write code in 'C' than in ASM for the 805x, I'm persuaded that those who are "smart" enough and diligent enough to produce high-quality 'C' code are also smart and diligent enough that they won't release "lousy" ASM.

Don't you think that customers will be happier with carefully designed meticulously crafted code that does precisely what's required and nothing else, than a bunch of quickly thrown-together bits of HLL to allow them to check their concept? I've been doing proof-of-concept work for decades, and can guarantee you that I've concluded that quickly generating a "rough cut" at a project hasn't produced good feedback for me.

I've explored the notion of using 'C' as the "glue" with which to string together numerous ASM modules/functions, often in the form of macros, thereby making the code easier to understand and to maintain. I've not yet persuaded myself that it does that. Making the bulk of the code ASM-based, does, however, make it fit the small model that the eval version of KEIL tolerates.

I can't address the various reasons for preferring 'C' for MCU's other than the 805x, as I generally program them in ASM as well ... even the RISC's that have been so popular.

RE