6502/SixtyPical
1
0
Fork 0
mirror of https://github.com/catseye/SixtyPical.git synced 2024-11-22 01:32:13 +00:00
Code Issues Projects Releases Wiki Activity

Try to improve the description in the documentation, and notes.

Browse Source
This commit is contained in:
Chris Pressey 2018-03-08 13:24:00 +00:00
parent 95fb2bb8f6
commit 2b9c457ffc
2 changed files with 19 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
HISTORY.md
View File

@ -19,6 +19,8 @@ History of SixtyPical
* Cleaned up the internals of the reference implementation (incl. the AST) * Cleaned up the internals of the reference implementation (incl. the AST)
and re-organized the example programs in the `eg` subdirectory. and re-organized the example programs in the `eg` subdirectory.
* Most errors produced by the reference implementation now include a line number. * Most errors produced by the reference implementation now include a line number.
* Compiler supports multiple preludes, specifically both Commodore 64 and
Commodore VIC-20; the `loadngo.sh` script supports both architectures too.
0.12 0.12
---- ----

20
README.md
View File

@ -3,13 +3,26 @@ SixtyPical
_Version 0.13. Work-in-progress, everything is subject to change._ _Version 0.13. Work-in-progress, everything is subject to change._
SixtyPical is a very low-level programming language, similar to 6502 assembly, **SixtyPical** is a 6502-assembly-like programming language with advanced
with static analysis through abstract interpretation. 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 concomittantly 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 In practice, this means it catches things like
* you forgot to clear carry before adding something to the accumulator * you forgot to clear carry before adding something to the accumulator
* a subroutine that you call trashes a register you thought was preserved * a subroutine that you call trashes a register you thought was preserved
* you tried to read or write a byte beyond the end of a byte array
* you tried to write the address of something that was not a routine, to * you tried to write the address of something that was not a routine, to
a jump vector a jump vector
@ -17,7 +30,8 @@ and suchlike. It also provides some convenient operations and abstractions
based on common machine-language programming idioms, such as based on common machine-language programming idioms, such as
* copying values from one register to another (via a third register when * copying values from one register to another (via a third register when
there are no underlying instructions that directly support it) there are no underlying instructions that directly support it); this
includes 16-bit values, which are copied in two steps
* explicit tail calls * explicit tail calls
* indirect subroutine calls * indirect subroutine calls