6502/SixtyPical
1
0
Fork 0
mirror of https://github.com/catseye/SixtyPical.git synced 2024-11-29 03:51:35 +00:00
Code Issues Projects Releases Wiki Activity

Update TODO

Browse Source
This commit is contained in:
Chris Pressey 2018-09-07 17:47:59 +01:00
parent 505fcb7b92
commit ff54a568a8
1 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
TODO.md
View File

@ -1,20 +1,16 @@
TODO for SixtyPical TODO for SixtyPical
=================== ===================
### `low` and `high` address operators ### 16-bit `cmp`
To turn `word` type into `byte`. This is because we don't actually want `low` and `high` address operators
that turn `word` type into `byte`.
Trying to remember if we have a compelling case for this or now. The best I can think This is because this immediately makes things harder (that is, effectively
of is for implementing 16-bit `cmp` in an efficient way. Maybe we should see if we impossible) to analyze.
can get by with 16-bit `cmp` instead though.
The problem is that once a byte is extracted, putting it back into a word is awkward. 16-bit `cmp` also benefits from some special differences between `cmp`
The address operators have to modify a destination in a special way. That is, when and `sub` on 6502, so it would be nice to capture them.
you say `st a, >word`, you are updating `word` to be `word & $ff | a << 8`, somelike.
Is that consistent with `st`? Well, probably it is, but we have to explain it.
It might make more sense, then, for it to be "part of the operation" instead of "part of
the reference"; something like `st.hi x, word`; `st.lo y, word`. Dunno.
### Save values to other-than-the-stack ### Save values to other-than-the-stack
@ -32,7 +28,7 @@ would be a good candidate for such.
Check that the buffer being read or written to through pointer, appears in appropriate Check that the buffer being read or written to through pointer, appears in appropriate
inputs or outputs set. inputs or outputs set.
In the analysis, when we obtain a pointer, we need to record, in contect, what buffer In the analysis, when we obtain a pointer, we need to record, in context, what buffer
that pointer came from. that pointer came from.
When we write through that pointer, we need to set that buffer as written. When we write through that pointer, we need to set that buffer as written.
@ -73,8 +69,8 @@ error.
More generally, define a block as having zero or one `goto`s at the end. (and `goto`s cannot More generally, define a block as having zero or one `goto`s at the end. (and `goto`s cannot
appear elsewhere.) appear elsewhere.)
If a block ends in a `call` can that be converted to end in a `goto`? Why not? I think it can. If a block ends in a `call` can that be converted to end in a `goto`? Why not? I think it can,
The constraints should iron out the same both ways. if the block is in tail position. The constraints should iron out the same both ways.
And - once we have this - why do we need `goto` to be in tail position, strictly? And - once we have this - why do we need `goto` to be in tail position, strictly?
As long as the routine has consistent type context every place it exits, that should be fine. As long as the routine has consistent type context every place it exits, that should be fine.
@ -86,3 +82,8 @@ Search a searchlist of include paths. And use them to make libraries of routine
One such library routine might be an `interrupt routine` type for various architectures. 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 Since "the supervisor" has stored values on the stack, we should be able to trash them
with impunity, in such a routine. 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.