3 ms·

Learning to write 6502 was a formative experience for me as a programmer and I strongly recommend it as a pedagogical exercise if nothing else. The instruction

Learning to write 6502 was a formative experience for me as a programmer and I strongly recommend it as a pedagogical exercise if nothing else. The instruction set is tiny, and easy to grapple with, but after learning it you'll get an intuitive grasp of, for instance, "why the C programming language is the way it is." So all that remains is to pick a platform! And there's no shortage of them. Glad to see Lynx is yet another participant in the vibrant 6502 homebrew community.

tellak 7y ago
> why the C programming language is the way it is. I’m curious specifically why you think this is. The 6502 with its poor register set and special purpose addressing mode seems to make it a relatively terrible/challenging C target.
- danmaz74 7y ago
  Not OP, but I learned assembly on the 6502, and its simplicity make it easy to create a mental model of the internals of a CPU - these relate very well with a low level language like c, even if today's CPUs are so much more advanced (and difficult to study).
  - duskwuff 7y ago
    Perhaps a better target might be the 68000, then? Still a relatively simple architecture, but one that more closely resembles a modern system -- multiple general-purpose registers, and ones which can be used as pointers without weird workarounds. (The 8-bit data / 16-bit address nature of the 6502 makes pointers complicated.)
    - danmaz74 7y ago
      Could be. Later I also worked with machine code on the 68K and it stuck to me less than the 6502, but it might just be because I felt that more like a chore than when I was dabbling with the 6502 (which I learned when I was just a kid).
  - nategri 7y ago
    OP here---you nailed it. Pointers and pointers-to-pointers can seem pretty abstract unless you work one level closer to the metal for a bit.
verisimilitudes 7y ago
>The instruction set is tiny, and easy to grapple with, but after learning it you'll get an intuitive grasp of, for instance, "why the C programming language is the way it is." If you want that, you should learn the PDP-11 instruction set, which is actually why the C language is the way it is. In particular, C is rather uniquely unsuited for segmented memory models, which many 6502 systems have, whereas other languages with lower-level features or accommodations can easily function under such a memory model, because they were designed with it in mind instead of solely for the PDP-11. On that note, C isn't actually a low-level language and I'm aware the 6502 is an example of an instruction set it maps very poorly to, compared to how a machine code programmer would approach it, so I'm curious why you made this relationship, since it's rather tenuous.
- duskwuff 7y ago
  > In particular, C is rather uniquely unsuited for segmented memory models C was often used to program 16-bit x86 systems, and it handled that well enough. A more relevant limitation of the 6502, however, is its stack. The 6502 stack is limited to a single page of 256 bytes, and there is no stack-relative addressing mode. This makes a C-style stack difficult to implement -- most C implementations for the 6502 implement a secondary data stack in main memory.
  - burfog 7y ago
    A good compiler would focus optimization efforts on removing variables from the stack. It would probably just reject programs that get silly with deep recursion. For example, if the compiler can prove that a function never gets more than one active stack frame (no recursion) then the local variables don't need to be on a stack. They can be in the data section. If the compiler can prove this for two functions together, such that they will never both have active stack frames, then the variables can reside in the same memory. Going beyond this, partial sharing is possible. If function X calls function Y, the variables of function Y can reside in the locations of many of the variables of function X. It is only the variables of function X that must survive the call to Y that would need distinct memory locations. Inlining can help too. That gets rid of the need to push a return address and so on.

tellak 7y ago

> why the C programming language is the way it is. I’m curious specifically why you think this is. The 6502 with its poor register set and special purpose addressing mode seems to make it a relatively terrible/challenging C target.

danmaz74 7y ago
Not OP, but I learned assembly on the 6502, and its simplicity make it easy to create a mental model of the internals of a CPU - these relate very well with a low level language like c, even if today's CPUs are so much more advanced (and difficult to study).
- duskwuff 7y ago
  Perhaps a better target might be the 68000, then? Still a relatively simple architecture, but one that more closely resembles a modern system -- multiple general-purpose registers, and ones which can be used as pointers without weird workarounds. (The 8-bit data / 16-bit address nature of the 6502 makes pointers complicated.)
  - danmaz74 7y ago
    Could be. Later I also worked with machine code on the 68K and it stuck to me less than the 6502, but it might just be because I felt that more like a chore than when I was dabbling with the 6502 (which I learned when I was just a kid).
- nategri 7y ago
  OP here---you nailed it. Pointers and pointers-to-pointers can seem pretty abstract unless you work one level closer to the metal for a bit.

verisimilitudes 7y ago

>The instruction set is tiny, and easy to grapple with, but after learning it you'll get an intuitive grasp of, for instance, "why the C programming language is the way it is." If you want that, you should learn the PDP-11 instruction set, which is actually why the C language is the way it is. In particular, C is rather uniquely unsuited for segmented memory models, which many 6502 systems have, whereas other languages with lower-level features or accommodations can easily function under such a memory model, because they were designed with it in mind instead of solely for the PDP-11. On that note, C isn't actually a low-level language and I'm aware the 6502 is an example of an instruction set it maps very poorly to, compared to how a machine code programmer would approach it, so I'm curious why you made this relationship, since it's rather tenuous.

duskwuff 7y ago
> In particular, C is rather uniquely unsuited for segmented memory models C was often used to program 16-bit x86 systems, and it handled that well enough. A more relevant limitation of the 6502, however, is its stack. The 6502 stack is limited to a single page of 256 bytes, and there is no stack-relative addressing mode. This makes a C-style stack difficult to implement -- most C implementations for the 6502 implement a secondary data stack in main memory.
- burfog 7y ago
  A good compiler would focus optimization efforts on removing variables from the stack. It would probably just reject programs that get silly with deep recursion. For example, if the compiler can prove that a function never gets more than one active stack frame (no recursion) then the local variables don't need to be on a stack. They can be in the data section. If the compiler can prove this for two functions together, such that they will never both have active stack frames, then the variables can reside in the same memory. Going beyond this, partial sharing is possible. If function X calls function Y, the variables of function Y can reside in the locations of many of the variables of function X. It is only the variables of function X that must survive the call to Y that would need distinct memory locations. Inlining can help too. That gets rid of the need to push a return address and so on.