1
0
mirror of https://github.com/catseye/SixtyPical.git synced 2024-06-06 15:29:30 +00:00

More edits to docs.

This commit is contained in:
Chris Pressey 2019-04-10 12:02:35 +01:00
parent 652ab1dc5c
commit 7854f71706
3 changed files with 24 additions and 9 deletions

View File

@ -17,6 +17,10 @@ History of SixtyPical
* Accessing a `table` through a `pointer` must be done in
the context of a `point ... into` block. This allows the
analyzer to check *which* table is being accessed.
* Refactored compiler internals so that type information
is stored in a single symbol table shared by all phases.
* Refactored internal data structures that represent
references and types to be immutable `namedtuple`s.
* Added `--dump-exit-contexts` option to `sixtypical`.
0.18

View File

@ -5,9 +5,8 @@ _Version 0.19. Work-in-progress, everything is subject to change._
**SixtyPical** is a [very low-level](#very-low-level) programming language
supporting a [sophisticated static analysis](#sophisticated-static-analysis).
Its reference compiler can generate [efficient code](#efficient-code) for
[several 6502-based platforms](#target-platforms) while catching many
several 6502-based [target platforms](#target-platforms) while catching many
common mistakes at compile-time, reducing the time spent in debugging.
Quick Start
@ -15,7 +14,7 @@ Quick Start
Make sure you have Python (2.7 or 3.5+) installed. Then
clone this repository and put its `bin` directory on your
executable search path. Then run:
executable search path. Then you can run:
sixtypical
@ -84,8 +83,8 @@ it conforms to it. It can detect common mistakes such as
Unlike most languages, in SixtyPical the programmer must manage memory very
explicitly, selecting the registers and memory locations to store all data in.
So, unlike a C compiler such as [cc65][], a SixtyPical compiler doesn't need
to generate code to handle stack management or register spilling. This results
in smaller (and thus faster) programs.
to generate code to handle [call stack management][] or [register allocation][].
This results in smaller (and thus faster) programs.
The flagship demo, a minigame for the Commodore 64, compiles to
a **930**-byte `.PRG` file.
@ -95,10 +94,12 @@ a **930**-byte `.PRG` file.
The reference implementation can analyze and compile SixtyPical programs to
6502 machine code formats which can run on several 6502-based 8-bit architectures:
* [Commodore 64][] -- examples in [eg/c64/](eg/c64/)
* [Commodore VIC-20][] -- examples in [eg/vic20/](eg/vic20/)
* [Atari 2600][] -- examples in [eg/atari2600/](eg/atari2600/)
* [Apple II series][] -- examples in [eg/apple2/](eg/apple2/)
* [Commodore 64][]
* [Commodore VIC-20][]
* [Atari 2600][]
* [Apple II series][]
For example programs for each of these, see [eg/README.md](eg/README.md).
Documentation
-------------
@ -117,6 +118,10 @@ and a reference implementation written in Python.
* [Output formats supported by `sixtypical`](doc/Output%20Formats.md)
* [TODO](TODO.md)
[effect system]: https://en.wikipedia.org/wiki/Effect_system
[abstractly interprets]: https://en.wikipedia.org/wiki/Abstract_interpretation
[call stack management]: https://en.wikipedia.org/wiki/Call_stack
[register allocation]: https://en.wikipedia.org/wiki/Register_allocation
[VICE]: http://vice-emu.sourceforge.net/
[cc65]: https://cc65.github.io/
[Commodore 64]: https://en.wikipedia.org/wiki/Commodore_64

View File

@ -46,4 +46,10 @@ Atari 2600 (4K cartridge). The directory itself contains a simple
demo, [smiley.60p](atari2600/smiley.60p) which was converted from an
older Atari 2600 skeleton program written in [Ophis][].
### apple2
In the [apple2](apple2/) directory are programs that run on
Apple II series computers (Apple II+, Apple //e). `sixtypical`'s
support for this architecture could be called embryonic.
[Ophis]: http://michaelcmartin.github.io/Ophis/