git @ Cat's Eye Technologies SixtyPical / 0.13
0.13

Tree @0.13 (Download .tar.gz)

SixtyPical

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

SixtyPical is a 6502-assembly-like programming language with advanced static analysis.

"6502-assembly-like" means that it has similar restrictions as programming in 6502 assembly (e.g. the programmer must choose the registers that values will be stored in) and is concomitantly easy for a compiler to translate it to 6502 machine language code.

"Advanced static analysis" includes abstract interpretation, where we go through the program step by step, tracking not just the changes that happen during a specific execution of the program, but sets of changes that could possibly happen in any run of the program. This lets us determine that certain things can never happen, which we can present as safety guarantees.

In practice, this means it catches things like

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

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

Quick Start

If you have the VICE emulator installed, from this directory, you can run

./loadngo.sh c64 eg/c64/hearts.60p

and it will compile the hearts.60p source code and automatically start it in the x64 emulator, and you should see:

Screenshot of result of running hearts.60p

You can try the loadngo.sh script on other sources in the eg directory tree. There is an entire small game(-like program) in demo-game.60p.

Documentation

TODO

for-like loop

We have range-checking in the abstract analysis now, but we lack practical ways to use it.

We can and a value to ensure it is within a certain range. However, in the 6502 ISA the only register you can and is A, while loops are done with X or Y. Insisting this as the way to do it would result in a lot of TXAs and TAXs.

What would be better is a dedicated for loop, like

for x in 0 to 15 {
    // in here, we know the range of x is exactly 0-15 inclusive
    // also in here: we are disallowed from changing x
}

However, this is slightly restrictive, and hides a lot.

However however, options which do not hide a lot, require a lot of looking at (to ensure: did you increment the loop variable? only once? etc.)

The leading compromise so far is an "open-faced for loop", like

ld x, 15
for x downto 0 {
    // same as above
}

This makes it a little more explicit, at least, even though the loop decrementation is still hidden.

Save registers on stack

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

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 adequately is probably not that hard.

And at some point...