hn-classics/_stories/1994/12536211.md

[Source](https://www.dwheeler.com/6502/a-lang.txt "Permalink to ")

A-LANG: WAYS TO IMPLEMENT COMPUTER LANGUAGES ON 6502s David A. Wheeler Here are some of ideas on how to create efficient and easy-to-use programming languages for 6502-based computers (such as the Apple II, Commodore 64/128, Atari 400/800, and the original Atari game machine). I haven't tried to implement these ideas at length, since I haven't directly used Apple II's (or any other 6502-based system) for some time (though there was a time I could rebuild an Apple II from memory!). For me, this is simply an intellectual exercise. I did create a partial prototype of some of these ideas, particularly some of the linking techniques. Still, this was an old problem that a friend of mine (Bob Pew) & I often hashed out. Bob passed away just when I completed writing the first draft of these ideas, and I was about to call him about my new ideas for this old puzzle we'd often chatted about. I miss him; perhaps this little file will serve as a small memorial to him. Perhaps some reader of this file actually DOES decide to do this. If you do: (a) are you SURE you don't have better things to do? (b) please let me know, I'd love to hear about it. Who knows; maybe the ideas of an "optimizing assembler" and "compiling linker" can be taken to other systems. It makes some sense, especially for systems where compilers are quickly written & can generate assembly, so that poor compiler code can be made a little better. It's possible these ideas have been created before, especially on far older systems. These are essentially notes, and are a little rough in places. There are probably a few minor bugs in various places. Sorry about that, but I think you'll still find them useful. \--- David A. Wheeler File originally created 1994-04-11 This version (slightly revised) 2009-07-18 ================================================================ BACKGROUND/THE PROBLEM The 6502 is a weird beast with a very irregular instruction set. Bob Pew & 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. This turns out to be an intellectually challenging problem; below are (what I think are) some solutions. There are many odd things about the 6502 that make it hard to do this: \+ It's REALLY an 8-bit processor. It doesn't even have 16-bit data registers or instructions (many other 8-bit chips, like the Z80, at least had these). That means that, where possible, use 8-bit manipulations instead of 16 or 32 bit data types. \+ Its instruction set is rather irregular and has a few odd addressing schemes (esp. "zero page"). \+ Its built-in stack (for subroutines) is only 256 bytes long - possibly enough for storing the return address, but probably not big enough for storing data as well. \+ ANY kind of stack access takes more time and uses up a (precious) register... which is why assembly language programs tended to pass values via fixed address locations. \+ It has a tiny amount of addressable memory, so for "big" programs, you need to conserve space. A key to using the 6502 is to keep as much as possible in the "zero page." The zero page is the first 256 bytes of memory; the 6502 has a large set of special operations that use this area of memory, in many ways like an extended register set. Loads and stores are faster to the zero page, and some operations (such as indirect addressing) REQUIRE use of the zero page. ======================================================== THE SOLUTIONS I have developed a few new (to my knowledge) solutions to this problem: 1\. Statically assign parameter and local variables in a special way. To do this, divide the work of compilation & linking in an unusual way (the linker does a ton of "compilation" work) to efficiently use 6502 resources, and in particular assign all local variables and parameters to static addresses. Global analysis is then used to assign addresses so that, in most cases, all copying between locations (e.g., between the addresses for parameters and addresses for local variables) are essentially optimized away. This could probabl
Initial commit 2018-02-23 18:19:40 +00:00			`[Source](https://www.dwheeler.com/6502/a-lang.txt "Permalink to ")`

			A-LANG: WAYS TO IMPLEMENT COMPUTER LANGUAGES ON 6502s David A. Wheeler Here are some of ideas on how to create efficient and easy-to-use programming languages for 6502-based computers (such as the Apple II, Commodore 64/128, Atari 400/800, and the original Atari game machine). I haven't tried to implement these ideas at length, since I haven't directly used Apple II's (or any other 6502-based system) for some time (though there was a time I could rebuild an Apple II from memory!). For me, this is simply an intellectual exercise. I did create a partial prototype of some of these ideas, particularly some of the linking techniques. Still, this was an old problem that a friend of mine (Bob Pew) & I often hashed out. Bob passed away just when I completed writing the first draft of these ideas, and I was about to call him about my new ideas for this old puzzle we'd often chatted about. I miss him; perhaps this little file will serve as a small memorial to him. Perhaps some reader of this file actually DOES decide to do this. If you do: (a) are you SURE you don't have better things to do? (b) please let me know, I'd love to hear about it. Who knows; maybe the ideas of an "optimizing assembler" and "compiling linker" can be taken to other systems. It makes some sense, especially for systems where compilers are quickly written & can generate assembly, so that poor compiler code can be made a little better. It's possible these ideas have been created before, especially on far older systems. These are essentially notes, and are a little rough in places. There are probably a few minor bugs in various places. Sorry about that, but I think you'll still find them useful. \--- David A. Wheeler File originally created 1994-04-11 This version (slightly revised) 2009-07-18 ================================================================ BACKGROUND/THE PROBLEM The 6502 is a weird beast with a very irregular instruction set. Bob Pew & 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. This turns out to be an intellectually challenging problem; below are (what I think are) some solutions. There are many odd things about the 6502 that make it hard to do this: \+ It's REALLY an 8-bit processor. It doesn't even have 16-bit data registers or instructions (many other 8-bit chips, like the Z80, at least had these). That means that, where possible, use 8-bit manipulations instead of 16 or 32 bit data types. \+ Its instruction set is rather irregular and has a few odd addressing schemes (esp. "zero page"). \+ Its built-in stack (for subroutines) is only 256 bytes long - possibly enough for storing the return address, but probably not big enough for storing data as well. \+ ANY kind of stack access takes more time and uses up a (precious) register... which is why assembly language programs tended to pass values via fixed address locations. \+ It has a tiny amount of addressable memory, so for "big" programs, you need to conserve space. A key to using the 6502 is to keep as much as possible in the "zero page." The zero page is the first 256 bytes of memory; the 6502 has a large set of special operations that use this area of memory, in many ways like an extended register set. Loads and stores are faster to the zero page, and some operations (such as indirect addressing) REQUIRE use of the zero page. ======================================================== THE SOLUTIONS I have developed a few new (to my knowledge) solutions to this problem: 1\. Statically assign parameter and local variables in a special way. To do this, divide the work of compilation & linking in an unusual way (the linker does a ton of "compilation" work) to efficiently use 6502 resources, and in particular assign all local variables and parameters to static addresses. Global analysis is then used to assign addresses so that, in most cases, all copying between locations (e.g., between the addresses for parameters and addresses for local variables) are essentially optimized away. This could probabl