mirror of
https://github.com/catseye/SixtyPical.git
synced 2024-11-25 23:49:17 +00:00
115 lines
4.3 KiB
Markdown
115 lines
4.3 KiB
Markdown
TODO for SixtyPical
|
|
===================
|
|
|
|
### 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 static
|
|
would be a good candidate for such.
|
|
|
|
### Analyze `call` within blocks?
|
|
|
|
What happens if you call another routine from inside a `with interrupts off` block?
|
|
|
|
What happens if you call another routine from inside a `save` block?
|
|
|
|
What happens if you call another routine from inside a `point into` block?
|
|
|
|
What happens if you call another routine from inside a `for` block?
|
|
|
|
Remember that any of these may have a `goto` ... and they may have a second
|
|
instance of the same block (e.g. `with interrupts off` nested within
|
|
`with interrupts off` shouldn't be allowed to turn them back on after the
|
|
inner block has finished -- even if there is no `call`.)
|
|
|
|
These holes need to be plugged.
|
|
|
|
### Reset pointer in `point into` blocks
|
|
|
|
We have `point into` blocks, but maybe the action when entering such a
|
|
block shouldn't always be to set the given pointer to the start of the given table.
|
|
|
|
That is, sometimes we would like to start at some fixed offset. And
|
|
sometimes we want to (re)set the pointer, without closing and starting a new block.
|
|
|
|
### 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.
|
|
|
|
### 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 more an impressive trick than a really useful feature, but still.
|
|
Impressive tricks are impressive.
|
|
|
|
### Locals with explicit addresses
|
|
|
|
A local could also be given an explicit address. In this case, two locals in
|
|
different routines could be given the same address, and as long as the condition
|
|
in the above paragraph holds, that's okay. (If it doesn't, the analyzer should
|
|
detect it.)
|
|
|
|
This would permit local pointers, which would be one way of addressing the
|
|
"same pointer to different tables" problem.
|
|
|
|
### 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.
|
|
|
|
### 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.)
|
|
|
|
### 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.
|
|
|
|
### Tail-call optimization
|
|
|
|
If a block ends in a `call` can that be converted to end in a `goto`? Why not? I think it can,
|
|
if the block is in tail position. The constraints should iron out the same both ways.
|
|
|
|
As long as the routine has consistent type context every place it exits, that should be fine.
|
|
|
|
### "Include" directives
|
|
|
|
Search a searchlist of include paths. And use them to make libraries of routines.
|
|
|
|
One such library routine might be an `interrupt routine` type for various architectures.
|
|
Since "the supervisor" has stored values on the stack, we should be able to trash them
|
|
with impunity, in such a routine.
|
|
|
|
### Line numbers 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.
|