[dzdt]

The 6502 is somewhat famously a hard target for the C language, and KickC does quite well at producing good results in spite of this. The C language is heavily based around pointers and stack usage. The 6502 has a minimal hardware stack: 256 bytes with no stack-relative addressing. So a "stack frame" is an alien concept that requires slow workarounds to emulate. And the 6502 only has pointers in the form of words stored in the first 256 bytes of RAM ("zero page") and also requires the use of one of the three registers to dereference.

[WalterBright]

The way to do it is to make a C-like language that has types and operators that map easily onto the 6502 architecture.

After all, C was designed to map onto the PDP-11 architecture - things like postincrement.

[polymipisexp]

The PDP-11 postincrement thing is very often repeated, and I'm sure there are good reasons to suspect it, but here is one bit of evidence to the contrary I find convincing

https://yarchive.net/comp/c.html

[billyjobob]

https://github.com/irmen/prog8

[flohofwoe]

There's also millfork which is a "mid-level" language specifically for 8-bit CPUs:

https://github.com/KarolS/millfork

[Joker_vD]

The 6502's stack is intended to be mostly a call stack, with maybe a temporary or two stored while you juggle the registers, not a place for your data frames. From what I vaguely recollect, the cc65 uses Y as the stack pointer, but only when it actually needs stack-like behaviour; at other times it uses static allocation a la Fortran, or so I think.