4 ms·

The 6502 is notoriously difficult to write a compiler for because it has only three general-purpose registers and it doesn’t have a stack-relative addressing mo

The 6502 is notoriously difficult to write a compiler for because it has only three general-purpose registers and it doesn’t have a stack-relative addressing mode, meaning there’s not really an efficient way to implement local variables. When writing 6502 assembly by hand, you usually just create a few global variables as “temporaries” for storage, parameter passing, etc. and you write your code carefully to make sure any subroutines you call don’t try to use a temporary you’re already using, or anything like that. Obviously, this doesn’t look anything like idiomatic C. For this reason, I’m really interested in seeing what kind of code this generates and how it performs, especially compared to the dominant 6502 compiler cc65 (https://cc65.github.io/ https://cc65.github.io/).

eschaton 5y ago
At least some 6502 operating systems used calling conventions to work around this. For example by putting a parameter “inline” after the JSR to a dispatcher, with the dispatcher fixing up the return address to skip the parameter on return. Then your activations can be anywhere in memory.
devit 5y ago
You can put a 16-bit stack pointer in the zeropage and address local variables with the (abs),Y address mode after having loaded the local variable index in Y with LDY #imm. The kernel needs to save the zeropage stack pointer on thread context switch, and of course this requires hardware zeropage mapping to work on SMP systems (not sure if 6502 SMP exists). If you want more than 256 bytes of local variables you will have to setup more offset copies of the stack pointer in the zero page first. Also most variables can be stored in the zeropage as caller-saved pseudo-registers and only spilled on the stack as needed. If you don't have threads or recursion then assigning fixed addresses is even better. It may however overall be much more space-efficient to implement a bytecode emulator for a proper 32/64-bit instruction set instead of trying to generate 6502 code.
- johnwbyrd 5y ago
  Your assumptions are correct.
johnwbyrd 5y ago
Disclaimer: I'm working on llvm-mos. https://llvm-mos.org/wiki/Rationale https://llvm-mos.org/wiki/Rationale

eschaton 5y ago

At least some 6502 operating systems used calling conventions to work around this. For example by putting a parameter “inline” after the JSR to a dispatcher, with the dispatcher fixing up the return address to skip the parameter on return. Then your activations can be anywhere in memory.

devit 5y ago

You can put a 16-bit stack pointer in the zeropage and address local variables with the (abs),Y address mode after having loaded the local variable index in Y with LDY #imm. The kernel needs to save the zeropage stack pointer on thread context switch, and of course this requires hardware zeropage mapping to work on SMP systems (not sure if 6502 SMP exists). If you want more than 256 bytes of local variables you will have to setup more offset copies of the stack pointer in the zero page first. Also most variables can be stored in the zeropage as caller-saved pseudo-registers and only spilled on the stack as needed. If you don't have threads or recursion then assigning fixed addresses is even better. It may however overall be much more space-efficient to implement a bytecode emulator for a proper 32/64-bit instruction set instead of trying to generate 6502 code.

johnwbyrd 5y ago
Your assumptions are correct.

johnwbyrd 5y ago

Disclaimer: I'm working on llvm-mos. https://llvm-mos.org/wiki/Rationale https://llvm-mos.org/wiki/Rationale