Well, how much say do we have over the architecture? Paging/banking hardware is pretty common on 6502-based systems. Such hardware decouples the virtual address space (what the CPU sees) from the physical address space. Typically they are used to extend memory space (e.g. the Apple //e's 80-column card) but they can also be used as a mass indirection mechanism (e.g. the NES's various "mappers", which granted are used more by its graphics coprocessor). The act of paging is "instantaneous" since you are just setting a hardware register.<p>So if you are designing the hardware, give it an extra 4 KiB or so (16 pages), mapped through a paging circuit to the zero page. On entry to a function, increment the current page; on exit, decrement. Now you have a way to push all "local variables" that is faster than even pushing all the registers. You could even get fancy and XOR bits 7-4 of the page register with bits 4-7 of the paged address lines, so the compiler can choose anywhere from 16 256-byte frames up to 256 16-byte frames.
Coincidentally, I was just reading this the other day. I've been programming for the Nintendo NES. The most common high level language that people use for NES Homebrew development is C with cc65[1]. The output of the compiler is passable, but C is just not well suited to the 6502 processor. Eventually I'd like to write a compiler for a high level language that used these ideas.<p>[1] <a href="http://cc65.github.io/cc65" rel="nofollow">http://cc65.github.io/cc65</a>
I remember... WAY back in the day... On the Ataris there was a language called Action! It was pretty good!<p><a href="https://en.wikipedia.org/wiki/Action!_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/Action!_(programming_language)</a>
"Use fixed zero page locations for
locals and parameter passing, simulating a
conventional CPU with a large register file. This
eliminates most stack operations, except for
saving/restoring the zero page"<p>The 65c816 allows the "zero page" (called the direct page there) to be relocated anywhere in the lower 64k. So if one targets that platform the saving/restoring operation could simply be one of pushing/popping the direct page location to/from the stack when entering or exiting function stack frames. Then just keep all program code above the 64k boundary.
I implemented a forth based language on C64 in 1983, it was tiny and fast. The 6502 was well suited to this. The REPL nature of forth languages is also perfect for machines with limited offline storage.
> I wanted a language that would be (a) faster to program in (than assembly) but be (b) fast when running. It needed to be pretty efficient.<p>Forth. Problem solved.
Not 6502 but the Zardoz 65816 compiler from back in the day (early nineties) had different memory models and one of the best allowed you to use the direct page register (essentially a moveable zero page) to access local variables in your functions. If you made some concessions to how you coded your C, you could end up with reasonably efficient code all things considered. It would be pretty cool to see a C like language that compiled efficiently for a stock 6502.
The author has more notes on the same topic elsewhere on his website, too (including reviews of Forths for 6502, PLASMA, and others): <a href="http://www.dwheeler.com/6502/" rel="nofollow">http://www.dwheeler.com/6502/</a>
So if you implemented a lisp on the 6502, you could run it on this emulator and then it'd be turtles all the way down?<p><a href="https://github.com/kingcons/cl-6502" rel="nofollow">https://github.com/kingcons/cl-6502</a>
I once had a pascal compiler for a 6502 machine:<p><a href="http://www.acornelectron.co.uk/info/electron/acornsoft/Spascal.html" rel="nofollow">http://www.acornelectron.co.uk/info/electron/acornsoft/Spasc...</a>
I think 6502 machines can do better with a version of BASIC that can compile into machine language binary files. One that has advanced commands for moving sprites and checking for collisions, etc. A BASIC compiler if you will?