mirror of
https://github.com/catseye/SixtyPical.git
synced 2024-11-22 01:32:13 +00:00
132 lines
4.2 KiB
Markdown
132 lines
4.2 KiB
Markdown
TODO for SixtyPical
|
|
===================
|
|
|
|
Language
|
|
--------
|
|
|
|
### Save values to other-than-the-stack
|
|
|
|
Allow
|
|
|
|
save a to temp_a {
|
|
...
|
|
}
|
|
|
|
Which uses some other storage location instead of the stack. A local non-static
|
|
would be a good candidate for such. At any rate, the location must not
|
|
be writeable by anything that is called from within the block. So, probably
|
|
just restrict this to local non-statics.
|
|
|
|
### Copy byte to/from table
|
|
|
|
Do we want a `copy bytevar, table + x` instruction? We don't currently have one.
|
|
You have to `ld a`, `st a`. I think maybe we should have one.
|
|
|
|
### Character literals
|
|
|
|
For goodness sake, let the programmer say `'A'` instead of `65`.
|
|
|
|
### Character set mapping
|
|
|
|
Not all computers think `'A'` should be `65`. Allow the character set to be
|
|
mapped. Probably copy what Ophis does.
|
|
|
|
### Pointers into non-byte tables
|
|
|
|
Right now you cannot get a pointer into a non-byte (for instance, word or vector) table.
|
|
|
|
Word and vector tables are stored as two byte tables in memory. This is useful for
|
|
indexed access, but makes pointer access more difficult.
|
|
|
|
Laying them out for pointer access would make indexed access more difficult.
|
|
|
|
### Saving non-byte values
|
|
|
|
Right now you cannot save a word value.
|
|
|
|
There doesn't seem to be a hugely pressing reason why not.
|
|
|
|
Analysis
|
|
--------
|
|
|
|
### Forbid recursion
|
|
|
|
What happens if a routine calls itself, directly or indirectly? Many
|
|
constraints might be violated in this case. We should probably disallow
|
|
recursion by default. (Which means assembling the callgraph in all cases.)
|
|
|
|
However note, it's okay for a routine to goto itself. It's a common
|
|
pattern for implementing a state machine, for a routine to tail-goto a
|
|
vector, which might contain the address of the same routine.
|
|
|
|
The problems only come up, I think, when a routine calls itself re-entrantly.
|
|
|
|
So the callgraph would need to distinguish between these two cases.
|
|
|
|
### Analyze memory usage
|
|
|
|
If you define two variables that occupy the same address, an analysis error ought
|
|
to be raised. (But there should also be a way to annotate this as intentional.
|
|
Intentionally making two tables overlap could be valuable. However, the analysis
|
|
will probably completely miss this fact.)
|
|
|
|
Optimization
|
|
------------
|
|
|
|
### Space optimization of local non-statics
|
|
|
|
If there are two routines A and B, and A never calls B (even indirectly), and
|
|
B never calls A (even indirectly), then their non-static locals can
|
|
be allocated at the same space.
|
|
|
|
This is not just an impressive trick -- in the presence of local pointers, which
|
|
use up a word in zero-page, which we consider a precious resource, it allow those
|
|
zero-page locations to be re-used.
|
|
|
|
Implementation
|
|
--------------
|
|
|
|
### Filename and line number in analysis error messages
|
|
|
|
For analysis errors, there is a line number, but it's the line of the routine
|
|
after the routine in which the analysis error occurred. Fix this.
|
|
|
|
### Better selection of options
|
|
|
|
`-O` should turn on the standard optimizations.
|
|
|
|
There should maybe be a flag to turn off tail-call optimization.
|
|
|
|
Some options should automatically add the appropriate architecture include
|
|
directory to the path.
|
|
|
|
Distribution
|
|
------------
|
|
|
|
### Demo game
|
|
|
|
Seems you're not be able to get killed unless you go off the top or bottom of
|
|
the screen? In particular, you cannot collide with a bar?
|
|
|
|
Blue-skying
|
|
-----------
|
|
|
|
### Pointers associated globally with a table(?)
|
|
|
|
We have `point into` blocks, but we would also like to sometimes pass a pointer
|
|
around to different routines, and have them all "know" what table it operates on.
|
|
|
|
We could associate every pointer variable with a specific table variable, in its
|
|
declaration. This makes some things simple, and would allow us to know what table a
|
|
pointer is supposed to point into, even if that pointer was passed into our routine.
|
|
|
|
One drawback is that it would limit each pointer to be used only on one table. Since a
|
|
pointer basically represents a zero-page location, and since those are a relatively scarce
|
|
resource, we would prefer if a single pointer could be used to point into different tables
|
|
at different times.
|
|
|
|
These can co-exist with general, non-specific-table-linked `pointer` variables.
|
|
|
|
If we have local pointers and space optimization for local non-statics, though,
|
|
these don't add as much.
|