SixtyPical

Version 0.12. Work-in-progress, everything is subject to change.

SixtyPical is a very low-level programming language, similar to 6502 assembly, with static analysis through abstract interpretation.

In practice, this means it catches things like

• you forgot to clear carry before adding something to the accumulator
• a subroutine that you call trashes a register you thought was preserved
• you tried to write the address of something that was not a routine, to a jump vector

and suchlike. It also provides some convenient operations and abstractions based on common machine-language programming idioms, such as

• copying values from one register to another (via a third register when there are no underlying instructions that directly support it)
• explicit tail calls
• indirect subroutine calls

The reference implementation can analyze and compile SixtyPical programs to 6502 machine code.

Documentation

• Design Goals
• SixtyPical specification
• SixtyPical revision history
• Literate test suite for SixtyPical syntax
• Literate test suite for SixtyPical execution
• Literate test suite for SixtyPical analysis
• Literate test suite for SixtyPical compilation
• 6502 Opcodes used/not used in SixtyPical

TODO

low and high address operators

To turn word type into byte.

Save registers on stack

This preserves them, so that, semantically, they can be used later even though they are trashed inside the block.

Range checking in the abstract interpretation

If you copy the address of a buffer (say it is size N) to a pointer, it is valid. If you add a value from 0 to N-1 to the pointer, it is still valid. But if you add a value ≥ N to it, it becomes invalid. This should be tracked in the abstract interpretation. (If only because abstract interpretation is the major point of this project!)

Range-checking buffers might be too difficult. Range checking tables will be easier. If a value is ANDed with 15, its range must be 0-15, etc.

Routine-local static memory locations

These would not need to appear in the inputs/outputs/trashes sets of the routines that call this routine.

These might be forced to specify an initial value so that they can always be assumed to be meaningful.

Union rule for trashes in if

If one branch trashes {a} and the other branch trashes {b} then the whole if statement trashes {a, b}.

Re-order routines and optimize tail-calls to fallthroughs

Not because it saves 3 bytes, but because it's a neat trick. Doing it optimally is probably NP-complete. But doing it adeuqately is probably not that hard.

And at some point...

• Check that the buffer being read or written to through pointer, appears in approporiate inputs or outputs set.
• interrupt routines -- to indicate that "the supervisor" has stored values on the stack, so we can trash them.
• error messages that include the line number of the source code
• add absolute addressing in shl/shr, absolute-indexed for add, sub, etc.
• automatic tail-call optimization (could be tricky, w/constraints?)
• st a, [ptr] + y, possibly ld x, [ptr] + y, possibly st x, [ptr] + y
• Maybe even copy [ptra] + y, [ptrb] + y, which can be compiled to indirect LDA then indirect STA!

Things it will not do

(this will be moved to a FAQ document at some point)

• Check that a vector is initialized before it's called.
• Check for recursive calls, or prevent bad things happening because of recursive calls. (You can always recursively call yourself through a vector.)