Update the spec re what literal integers in the code mean.
Chris Pressey
4 years ago
13 | 13 | Types |
14 | 14 | ----- |
15 | 15 | |
16 | There are seven *types* in SixtyPical: | |
16 | There are five *primitive types* in SixtyPical: | |
17 | 17 | |
18 | 18 | * bit (2 possible values) |
19 | 19 | * byte (256 possible values) |
20 | * byte table (256 entries, each holding a byte) | |
21 | 20 | * word (65536 possible values) |
22 | * word table (256 entries, each holding a word) | |
23 | 21 | * routine (code stored somewhere in memory, read-only) |
24 | 22 | * vector (address of a routine) |
23 | ||
24 | There is also one *type constructor*: | |
25 | ||
26 | * X table (256 entries, each holding a value of type X) | |
27 | ||
28 | This constructor can only be applied to bytes or words. | |
25 | 29 | |
26 | 30 | Memory locations |
27 | 31 | ---------------- |
110 | 114 | trashes y |
111 | 115 | @ $c000 |
112 | 116 | |
113 | > TODO: need to confirm this, but, the rule is: | |
114 | > | |
115 | > * If it is NAMED, it is a memory address. | |
116 | > * If it is a LITERAL INTEGER, it is an immediate value. | |
117 | > | |
118 | > However, this really needs a review, deep in the code, for how this is implemented. | |
117 | Note that in the code of a routine, if a memory location is named by a | |
118 | user-defined symbol, it is an address in memory, and can be read and written. | |
119 | But if it is named by a literal integer, either decimal or hexadecimal, it | |
120 | is a constant and can only be read (and when read always yields that constant | |
121 | value. So, for instance, to read the value at `screen` above, in the code, | |
122 | you would need to reference the symbol `screen`; attempting to read 1024 | |
123 | would not work. | |
124 | ||
125 | This is actually useful, at least at this point, as you can rely on the fact | |
126 | that literal integers in the code are always immediate values. (But this | |
127 | may change at some point.) | |
119 | 128 | |
120 | 129 | Routines |
121 | 130 | -------- |