It's still a decent machine for C especially when compared with, say, 8051. I'm currently developing an entire product line based on a '51 derivative and just seeing what kind of assembly Keil C51 compiler produces is enough to make my eyes bleed. The amount of kludges required to make C work on that architecture is horrifying. Want an example? There's no stack when running under C51.

There's certainly a stack when running under C51, for function call returns. C51 just assigns local variables into 128 byte data segment. But say, PUSH ACC works just fine when you drop into assembler.

Then again, stack on 8051 might be sometimes pretty small. From 10 to 128+ bytes.

Right. Still, the fact that local variables aren't stack- but overlay- based is enough to blow my mind.

Yeah. The small device I am most familiar with is the z80, which is really not a good C machine either.

AVR was basically designed from the ground up to be a good platform for C. It's fairly RISC-like, registers are for the most part interchangeable, it has enough pointer registers to support a standard C-style stack and still have two left over for actual pointers, etc.

In fact, does anyone know whether LLVM/GCC can target AVR well? I recently had the displeasure of staring at what sdcc produces from pretty reasonable-looking C... (it doesn't help that some 8-bit microcontrollers are really not C processors.)

I wrote a bunch of stuff for the AVR in c. But it's been a few years since I've done much more than a few fixes. Some of the weird issues with targeting a Harvard architecture is I think fixed.

I'd say: 'works okay'

One thing that annoyed me was calling a variadic function like printf was expensive ~100-120 bytes each call. Eight to Ten printf's --> 1k of flash gone. Far as I could tell most of it was pushing and popping stuff on the stack one byte at a time.

I ported a bunch of AVR code to an ARM Cortex[1]. Code size didn't increase much.

[1] ARM Processors are approximately half the cost of an AVR. Seriously not important if you're building 1000's of something. Important if you're building 100,000s.

GCC at least is just fine. Was involved in developing an embedded system which was controlled by an AVR. There were some cases of unexpectedly big program sizes. But most was due to using large integers unnecessary (higher than 8 bit) and one case of overly aggressive inlining. Don't remember offhand how we solved the last one, but just took a day or two.

Are you thinking of PIC microcontrollers maybe? AFAIK all AVRs are 8-bit and the architecture was designed to be easily targeted by compilers.