First of all, I believe you're probably right as to the ratio you suggest, with typical (poorly organized) code, regardless of whether it's in HLL or ASM.

Secondly, the ratio varies as the code size. If a guy is writing code that has to fit into 2kB, as in a "small" MCU, then he might be better off writing it in ASM because it's pretty easy to manage a file of about 10kB of text, which might assemble down to about 2 kB of binary. I've found that an object file of about 8kB generally springs from about 32 kB of assembly language. I don't know why a 'C' program that produces 8 kB of binary would be any less difficult to manage than 32 kB of ASM, since 'C' is so much denser than ASM.

Now, I was a HLL (mostly FORTRAN) programmer back in college and shortly thereafter, but, since the '70's, I've written mostly in ASM since then. I haven't found the ratios that have been bandied about here to be absolutes, though they certainly can occur. I don't find ASM as difficult to debug as HLL, and I don't find ASM as difficult to design as HLL. Once I get into the mode of thinking and writing in the instruction set and architecture of the MCU, it becomes quite clear how to do what needs to be done.

My own focus is generally on getting the job done at minimal cost, and not just to me but to those for whom I'm doing it. I don't want to force my clients to use a particular compiler, because, then, they have to buy it. Further, if they want to use a particular compiler, then I have to buy it. Up to now, not one of my clients has expressed a desire to use or to buy a compiler. They let me decide on what tools to use, and I provide them a copy of the "free" tools I use.

Now, while Erik and Andy have been using 805x HLL for a long time, at the start of which they probably knew the 805x quite thoroughly, they were quite qualified to choose their tools for that reason. I don't disagree that well-written HLL can make the maintenance of a sizeable body of code much easier to maintain. However, I have doubts as to whether extensive maintenance, beyond a few minor tweaks, is often necessary, as I've observed that products with long market life are scarce and over those few long market lives, the entire innards of the device are often completely changed, including the MCU and the associated peripherals. If the changes were just maintenance, then yes, HLL would have been convenient. However, the projects that I've most recently worked on, at least those that were 805x-based, were created in the early '80's, built on commercial 805x boards, and have been "upgraded" by dropping in a one-clocker on a daughterboard, with hardware to make it "play" with the old existing hardware. Those required relatively straightforward, though sometimes large, code mods, and HLL would not, IMHO, have helped me, or anyone else, a bit.

I'm of the opinion that a newbie who wants to start with a "small" MCU has a really hard row to hoe. It's easy taking a somewhat later generation, not necessarily "bleeding edge," MCU with a large on-chip code space, or even an older one with external code memory, and putzing around in ASM with the aid of a monitor in some sort of ROM, just to learn to use the core. When he's ready to do a serious piece of production work, he will then understand the basics, i.e. timers, counters, register set, flags, etc. not to mention the quirks and foibles of the instruction set. I don't maintain that ASM coupled with ULTRAMON51 is the only or even the best way to do production work, but it's a very straightforward way to develop hobby projects, and it doesn't cost a semester's tuition.

I doubt Andy or Erik would have easily succeeded plowing up new ground with HLL if they hadn't already possessed a firm knowledge of the 805x core.

RE