C compiled for the 6502 would use the zero page (first 256 bytes of RAM) as registers, and use the actual registers just to run instructions of a higher-level abstract machine that, e.g., understood 16-bit numbers. Kind of like Xerox Alto, in that particular way; on the Alto, only device drivers were coded native.

There was a C compiler that kept one of the 6502 index registers zero at all times, just to have a zero handy.

This use of a little interpreter to provide a higher-level instruction architecture to program to was really, really common in the 50s and 60s. The Apollo AGC computer that landed on the moon was mostly programmed that way. It seems surprising that with memory so tight, they would use up so much of it for the virtual machine interpreter, but instructions for that could be much more compact than native code. It made a slow computer even slower, but they all felt fast back then.

Steve Wozniak burned a little interpreter like that into the Apple ][ ROM, just smart enough for dumb jobs like copying blocks of memory. It used a reserved fragment of the zero page as its registers.

These processors were designed for assembly programming, hence their very CISC-y ISA. Some 8-bitters designed for compiled languages would be the AVR family.

That's too generous. They were primarily designed for what was easy to implement and what _could_ be handled in assembly. Also, 8080 was an evolution of the 4040 (and that owed much to the 4004). Z80 had to be compatible with the 8080... I know less of 6502 but most of them were designed about what could be done, not what would be easy to program.

I actually only recently learned that the 8008/8080 was in fact not based on the 4004/4040 instruction set. They used the same numbering system, but the ISA has little to nothing in common with it and in fact the 8008 project was in started before the 4004:

https://sites.google.com/site/microprocessorintel4004/8008-8...

Thanks I might misremember. Regradless, 8080 is still awful and they could have sone better with more foresight (which is easy to say so many decades later).

When you’ve got hardly any registers you don’t have any choices how to allocate them. What’s maddening is a chip like the 8086 where you have enough registers that how you allocate them matters, but still very little space to work in. You are left working hard on a register allocator that is still not going to be very food.

In theory, a smart compiler could make heavy use of the DP register (6809 feature) and then local variables within a compiled function could access these "fast" global variables instead. This was a common pattern when coding in assembly, and it's much faster than accessing variables off the stack. The function wouldn't be reentrant, but a compiler pragma could be used to enable/disable the DP mode. Declaring the local variables as static should be sufficient, however.

The WDC C compiler for the 65816 takes advantage of this (relocatable direct page). And the relocatable stack. In fact I believe what it does is relocate the stack to at least partially overlap the direct page.

It's still an awkward target though.

Back then, memory was only one cycle away, so was practically registers. This is why the 6502 zero page was so important. 6502 instructions took very few cycles, so you could move a zero-page byte to the accumulator in 3 cycles, sometimes 2, and is why a $25 6502 could match a $200 Z80.

Z80 had a faster clock, but instructions took loads of cycles. Nowadays that is OK, but Z80 did not pipeline. It had fancy looping instructions, but they ran slower than the loop would have.

I wrote a multi-tasking OS for the 6809 and used the DP to hold the current task ID: task local variables would be in the direct page.