mirror of
https://github.com/catseye/SixtyPical.git
synced 2025-02-19 05:30:42 +00:00
Update HISTORY and README.
This commit is contained in:
parent
c3a1bdb4cc
commit
a73f6e1d94
10
HISTORY.md
10
HISTORY.md
@ -4,10 +4,8 @@ History of SixtyPical
|
||||
0.16
|
||||
----
|
||||
|
||||
* Removed `--prelude` in favour of specifying both format and prelude
|
||||
with a single option, `--output-format`. Documentation for same.
|
||||
* `or a, z`, `and a, z`, and `eor a, z` compile to zero-page operations
|
||||
if the address of z < 256.
|
||||
* Added `save` block, which allows the named locations to be modified
|
||||
arbitrarily inside the block, and automatically restored at the end.
|
||||
* More thorough tests and justifications written for the case of
|
||||
assigning a routine to a vector with a "wider" type.
|
||||
* Support for `copy [ptra]+y, [ptrb]+y` to indirect LDA indirect STA.
|
||||
@ -15,6 +13,10 @@ History of SixtyPical
|
||||
* Support for `I a, btable + x` where `I` is `add`, `sub`, `cmp`,
|
||||
`and`, `or`, or `xor`
|
||||
* Support for `I btable + x` where `I` is `shl`, `shr`, `inc`, `dec`
|
||||
* `or a, z`, `and a, z`, and `eor a, z` compile to zero-page operations
|
||||
if the address of z < 256.
|
||||
* Removed `--prelude` in favour of specifying both format and prelude
|
||||
with a single option, `--output-format`. Documentation for same.
|
||||
|
||||
0.15
|
||||
----
|
||||
|
24
README.md
24
README.md
@ -87,28 +87,30 @@ 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
|
||||
### Save multiple values in single block
|
||||
|
||||
This preserves them, so that, semantically, they can be used later even though they
|
||||
are trashed (or otherwise alternately used) inside the block.
|
||||
|
||||
Inside the block, we set them as writeable (but not meaningful). When the block
|
||||
exits, we restore whatever status they had.
|
||||
|
||||
This act will trash `a`, both in the block, and outside it, unless the value being
|
||||
saved is `a`. One idiom would be something like
|
||||
As a shortcut for the idiom
|
||||
|
||||
save a { save var {
|
||||
...
|
||||
} }
|
||||
|
||||
which would save all values. Maybe abbreviate this to
|
||||
allow
|
||||
|
||||
save a, var {
|
||||
...
|
||||
}
|
||||
|
||||
This can use the stack. But it need not use the stack.
|
||||
### 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.
|
||||
|
||||
### Make all symbols forward-referencable
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user