6502/SixtyPical
1
0
Fork 0
mirror of https://github.com/catseye/SixtyPical.git synced 2024-06-07 06:29:32 +00:00
Code Issues Projects Releases Wiki Activity

Refine documentation.

Browse Source
This commit is contained in:
Chris Pressey 2018-02-12 14:31:26 +00:00
parent 79d7c8d198
commit 5c3c560fe4
2 changed files with 32 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
README.md
View File

@ -66,22 +66,15 @@ is probably NP-complete. But doing it adeuqately is probably not that hard.
### And at some point...
* `const`s, that can be used in defining the size of tables, etc
* `const`s that can be used in defining the size of tables, etc.
* Remove the need for `forward` and `vector () table` (make grammar changes)
* Tests, and implementation, ensuring a routine can be assigned to a vector of "wider" type
* Check that the buffer being read or written to through pointer, appears in approporiate inputs or outputs set.
(Associate each pointer with the buffer it points into.)
* `static` pointers -- currently not possible because pointers must be zero-page, thus `@`, thus uninitialized.
* `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?)
* possibly `ld x, [ptr] + y`, possibly `st x, [ptr] + y`
* 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?)
* 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.)

25
doc/Design Goals.md
View File

@ -26,6 +26,31 @@ 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.