/
TODO.txt
275 lines (193 loc) · 8.02 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
// Various build options to test with:
// $(ProjectDir)
// -v9 Test.a
// -v9 TestACME.a
// C:\work\C64\Scroller
// -v3 --msvc ScrollEntry.a
// C:\work\c64\Tusari2
// -v4 --msvc --lib ../Scroller/ ScrollEntry.a ScrollEntry_Tusari.a ScrollEntryAfter.a
// --lib ../C64/stdlib/ -v9 --pdb target\TestLabelDefined.pdb --labeldump target\TestLabelDefined.lbl TestLabelDefined.a
ACME TODO file.
* Now the PDB debugger can understand multiple contexts for the same address, perhaps output the root real source file information when inside macro(s)?
This would be the first real source file line before the macro is called...
Or perhaps every level where a macro is entered?
When debugging Demo6 for example and MAPU_LoadDoWait is used, it would be nice to be able to switch to the source file that uses the macros...
* When running Vice without "-moncommands TestIRQDisk.lbl" make the disassembly enrich better, to spot labels and potentially immediate values
The Vice disassembly with labels in "8:" does not entirely work correctly, so it's better not to run with those labels loaded.
Use the device and the zone information to pick the correct labels from the PDB
The disassembly address needs the label name inserted on it's own line, preferably.
Immediate values could retain the value in parenthesis.
* To enhance python debugging with PDB, it is possible to output the code that python emits (send to the assembler) to a temporary file and write PDB entries for that file
Similar to EnrichDumpWithMemory but create a new method.
* A label with "start" and a local label ".start" need to be differentiated in the lbl/map/pdb files to avoid the situation where this gets confusing results: And I load labels "foo"
This was picking up the wrong start address: When I execute the procedure at start for no more than 194 instructions
* Currently is the remote debugger displays source for a memory address, but that memory address as two or more mappings, the results can be confusing.
Have the option to filter the source display by a list of zones, if more than one zone is found for an address range
Pick by zone and display the filename along with the zone
This was apparent when trying to display source for the APU, but it can also happen if combined PDBs are loaded for cartridge or multi-load code
* The PDB output from ACME also needs to include extra ADDR chunks for addresses that overlap due to !pseudopc and !device usage
* The PDB read needs to store device memory mappings separately
>> ** When reading multiple PDBs (which could obviously have the same zone number) the base zone number (zone 0) is adjusted by the highest zone value (minus device) loaded so far, plus 1...
Note this following code isn't quite accurate, it needs to track the maximum some from the ADDRS section as well...: mLabelInfoByZone.Keys.Max()
>> * Add a tab to the "break" view showing a list of zones that are active for the current memory address?
Also use the device from the currently selected view
> If there are multiple entries for the same address, but different zones, these could have different previous/next memory addresses in the AddrInfo because the source code context is different
This causes problems for the mixed source and disassembly view since the current zone/device/context would need to be known
> OnContextChecked OnContextUnchecked
// TODO: Implement filtering
mContextList
>> // TODO: This must come from the PDB info and maintain its Enable state
* Add option to save out breakpoints in the source to a file suitable for use in Vice
Create an empty file if no breakpoints flagged
Remember to include the device and address. e.g.
break c:1234
* Command line option to define labels
* Look into structure storage and label generation. A '.' is an undefined value, no default value when being used
!struct SomeData {
a !by .
b !by .
c !word .
}
Will create the labels with offsets to the named members:
SomeData_a = 0
SomeData_b = 1
SomeData_c = 2
Then using it with:
* = $100
someLabel +SomeData 4 , 5 , 1234
Will automatically create data in memory according to the structure with these variables:
someLabel_a = $100
someLabel_b = $101
someLabel_c = $102
someLabel_SomeData_a = 0
someLabel_SomeData_b = 1
someLabel_SomeData_c = 2
* Look into VSCode remote debugging into Vice with PDB parsing to enhance the source view
* Look into VS to Vice debugging with ACME
https://blog.3d-logic.com/2012/05/12/introducing-vintage-studio/
* Code re-ordering and register optimisation
Especially the case where we have code like this:
!macro FOO {
lda #$ff
sta address
}
!macro BAR {
lda #$ff
sta address2
}
+FOO
+BAR
This would typically result in output code:
lda #$ff
sta address
lda #$ff
sta address2
Instead optimise this so that it results in:
lda #$ff
sta address
sta address2
This can be done if there are no references to branch/jump/indrect/store in-between the two stores.
>> Shifted 16 bit values:
lda .workOffset
sec
sbc #3
sta .workOffset
bcs .noBorrow
dec .workOffset+1
.noBorrow
;workOffset = ((workOffset-3)<<8) + source[curLen];
lda .workOffset
sta .workOffset+1
jsr ReturnA...
sta .workOffset
Can become:
lda .workOffset
sec
sbc #3
; Note: The bottom byte is discarded due to the result <<8, the top byte is replaced...
sta .workOffset+1
jsr ReturnA...
sta .workOffset
* Dead strip code in zones where labels (their memory addresses) are not referenced at all by anything outside that zone.
* Add assembler zone documentation
!entry - Document entry status/register/memory locations
!return - Document returned status/register/memory locations
!trashed - Document trashed status/register/memory locations. Like !return but makes the unknown/trashed state explicit.
!preserve - Make status/register/memory explicitly preserved
!irq - Flag this as IRQ code
When any of the above are used then also track all status/register/memory usage for the zone
* Use the assembler zone documentation and static analysis to warn when conflicting status/register/memory locations are used in code.
If the calling zone uses status/register/memory that the called zone does then output an error.
For example:
!zn {
!return A
foo
lda #0
>>Warning doThing trashes A>> jsr doThing
rts
}
!zn {
!entry
!return
doThing
lda #0
rts
* When !irq is used, analyse the code to ensure that !preserve registers/locations are restored
* Optimising assembly with zone using !optimise
Use the assembler zone documentation and static analysis to automatically pick optimisations for a zone
For example:
!zn {
!optimise speed
!entry Y
!return X , EQ ; Returns X and one of the EQ/NE status
!trash A , Y , CC , VS , MI ; Can trash registers and CC/CS VC/VS MI/PL status
foo
iny
iny
iny
iny
tya
; Flags that this is the instruction that will return the destination in X
!return tax
; If any code alters X after this !return, in this scope, then an assembler error is generated
rts
}
Would optimise to:
foo
tya
clc
adc #4
tax
rts
>> Or:
lda #0
sta workLen
sta workLen+1
jsr GetNextBitIntoCarryKillA
rol workLen
jsr GetNextBitIntoCarryKillA
rol workLen
lda workLen
ora workLen+1
bne not0
lda #1
sta .workLen
>> Optimises to:
lda #0
sta .workLen
sta .workLen+1
jsr .GetNextBitIntoCarryKillA
rol .workLen
jsr .GetNextBitIntoCarryKillA
rol .workLen
; Note: Status from above
bne .not0
; Equivalent since .workLen = 0
inc .workLen
* !range <label> , <start> , <end> , <step>
Like !for but has more options for start and step values
* !bank <bank number>
Creates or accesses new 64KB (up to) memory banks which allows code/data to be huge.
The corresponding PC is maintained for each bank.
Each bank is saved as a distinct file, new addition to the base filename.
The PDB would need bank information and the remote debugger would need some way of identifying the bank being executed, perhaps by noting the current cartridge bank select by reading any active cartridge IO space from Vice/BDD6502.