From 5c3c560fe4cf625beea019cdc611584913fd4187 Mon Sep 17 00:00:00 2001 From: Chris Pressey Date: Mon, 12 Feb 2018 14:31:26 +0000 Subject: [PATCH] Refine documentation. --- README.md | 21 +++++++-------------- doc/Design Goals.md | 25 +++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 6def8c8..b104d0c 100644 --- a/README.md +++ b/README.md @@ -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.) diff --git a/doc/Design Goals.md b/doc/Design Goals.md index 874a44c..e8847c6 100644 --- a/doc/Design Goals.md +++ b/doc/Design Goals.md @@ -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.