mirror of
https://github.com/catseye/SixtyPical.git
synced 2024-11-22 01:32:13 +00:00
78 lines
3.3 KiB
Markdown
78 lines
3.3 KiB
Markdown
Design Goals for SixtyPical
|
|
===========================
|
|
|
|
(draft)
|
|
|
|
The intent of SixtyPical is to have a very low-level language that
|
|
benefits from abstract interpretation.
|
|
|
|
"Very low-level" means, on a comparable level of abstraction as
|
|
assembly language.
|
|
|
|
In the original vision for SixtyPical, SixtyPical instructions mapped
|
|
nearly 1:1 to 6502 instructions. However, many times when programming
|
|
in 6502 you're using idioms (e.g. adding a 16-bit constant to a 16-bit
|
|
value stored in 2 bytes) and it's just massively easier to analyze such
|
|
actions when they are represented by a single instruction.
|
|
|
|
So SixtyPical instructions are similar to, inspired by, and have
|
|
analogous restrictions as 6502 instructions, but in many ways, they
|
|
are more abstract. For example, `copy`.
|
|
|
|
The intent is that programming in SixtyPical is a lot like programming
|
|
in 6052 assembler, but it's harder to make a stupid error that you have
|
|
to spend a lot of time debugging.
|
|
|
|
The intent is not to make it absolutely impossible to make such errors,
|
|
just harder.
|
|
|
|
### Things it will Not Do ###
|
|
|
|
To emphasize the point, the intent is not to make it impossible to make
|
|
data-usage (and other) errors, just harder.
|
|
|
|
Here are some things SixtyPical will not try to detect or prevent you
|
|
from doing:
|
|
|
|
* Check that a vector is initialized before it's called.
|
|
* Check that the stack has enough room on it.
|
|
* Prevent bad things happening (e.g. clobbering a static storage
|
|
location) because of a recursive call. (You can always recursively
|
|
call yourself through a vector.)
|
|
* Check that reads and writes to a buffer are in bounds. (This may
|
|
happen someday, but it's difficult. It's more likely that this
|
|
will happen for tables, than for buffers.)
|
|
|
|
At one point I wanted to do a call-tree analysis to find sets of
|
|
routines that would never be called together (i.e. would never be on
|
|
the call stack at the same time) and allow any static storage locations
|
|
defined within them to occupy the same addresses, i.e. allow storage
|
|
to be re-used across these routines. But, in the presence of vectors,
|
|
this becomes difficult (see "Prevent bad things happening", above.)
|
|
Also, it would usually only save a few bytes of storage space.
|
|
|
|
### Some Background ###
|
|
|
|
The ideas in SixtyPical came from a couple of places.
|
|
|
|
One major impetus was when I was working on [Shelta][], trying to cram
|
|
all that code for that compiler into 512 bytes. This involved looking
|
|
at the x86 registers and thinking hard about which ones were preserved
|
|
when (and which ones weren't) and making the best use of that. And
|
|
while doing that, one thing that came to mind was: I Bet The Assembler
|
|
Could Track This.
|
|
|
|
Another influence was around 2007 when "Typed Assembly Language" (and
|
|
"Proof Carrying Code") were all the rage. I haven't heard about them
|
|
in a while, so I guess they turned out to be research fads? But for a
|
|
while there, it was all Necula, Necula, Necula. Anyway, I remember at
|
|
the time looking into TAL and expecting to find something that matched
|
|
the impression I had pre-formulated about what a "Typed Assembly"
|
|
might be like. And finding that it didn't match my vision very well.
|
|
|
|
I don't actually remember what TAL seemed like to me at the time, but
|
|
what I had in mind was more like SixtyPical.
|
|
|
|
(I'll also write something about abstract interpretation here at some
|
|
point, hopefully.)
|