6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-11 13:50:13 +00:00
Code Issues Projects Releases Wiki Activity
9784ad043e
6502bench/SourceGen/SGTestData/20290-region-isolation.dis65

420 lines
6.1 KiB
Plaintext
Raw Normal View History

Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
### 6502bench SourceGen dis65 v1.0 ###
{
"_ContentVersion":6,
"FileDataLength":1537,
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
"FileDataCrc32":-1543685807,
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
"ProjectProps":{
"CpuName":"6502",
"IncludeUndocumentedInstr":false,
"TwoByteBrk":false,
"EntryFlags":32702671,
"AutoLabelStyle":"Simple",
"AnalysisParams":{
"AnalyzeUncategorizedData":true,
"DefaultTextScanMode":"LowHighAscii",
"MinCharsForString":4,
"SeekNearbyTargets":true,
"UseRelocData":false,
"SmartPlpHandling":false,
"SmartPlbHandling":true},
"PlatformSymbolFileIdentifiers":[],
"ExtensionScriptFileIdentifiers":[],
"ProjectSyms":{
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
"IN_1":{
"DataDescriptor":{
"Length":256,
"Format":"NumericLE",
"SubFormat":"Hex",
"SymbolRef":null},
"Comment":"",
"HasWidth":true,
"Direction":"ReadWrite",
"MultiMask":null,
"Label":"IN_1",
"Value":36864,
"Source":"Project",
"Type":"ExternalAddr",
"LabelAnno":"None"},
"IN_2":{
"DataDescriptor":{
"Length":256,
"Format":"NumericLE",
"SubFormat":"Hex",
"SymbolRef":null},
"Comment":"",
"HasWidth":true,
"Direction":"ReadWrite",
"MultiMask":null,
"Label":"IN_2",
"Value":40960,
"Source":"Project",
"Type":"ExternalAddr",
"LabelAnno":"None"},
"IN_3":{
"DataDescriptor":{
"Length":256,
"Format":"NumericLE",
"SubFormat":"Hex",
"SymbolRef":null},
"Comment":"",
"HasWidth":true,
"Direction":"ReadWrite",
"MultiMask":null,
"Label":"IN_3",
"Value":45056,
"Source":"Project",
"Type":"ExternalAddr",
"LabelAnno":"None"},
"IN_4":{
"DataDescriptor":{
"Length":256,
"Format":"NumericLE",
"SubFormat":"Hex",
"SymbolRef":null},
"Comment":"",
"HasWidth":true,
"Direction":"ReadWrite",
"MultiMask":null,
"Label":"IN_4",
"Value":49152,
"Source":"Project",
"Type":"ExternalAddr",
"LabelAnno":"None"},
"THREE_K":{
"DataDescriptor":{
"Length":1,
"Format":"NumericLE",
"SubFormat":"Hex",
"SymbolRef":null},
"Comment":"project symbol test",
"HasWidth":false,
"Direction":"ReadWrite",
"MultiMask":null,
"Label":"THREE_K",
"Value":12288,
"Source":"Project",
"Type":"ExternalAddr",
"LabelAnno":"None"}}},
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
"AddressMap":[{
"Offset":0,
"Addr":2048,
"Length":256,
"PreLabel":"",
"DisallowInward":false,
"DisallowOutward":false,
"IsRelative":false},
{
"Offset":45,
"Addr":2093,
"Length":12,
"PreLabel":"",
"DisallowInward":false,
"DisallowOutward":true,
"IsRelative":true},
{
"Offset":256,
"Addr":4096,
"Length":256,
"PreLabel":"",
"DisallowInward":true,
"DisallowOutward":true,
"IsRelative":false},
{
"Offset":512,
"Addr":4096,
"Length":256,
"PreLabel":"",
"DisallowInward":false,
"DisallowOutward":false,
"IsRelative":false},
{
"Offset":537,
"Addr":36864,
"Length":18,
"PreLabel":"inner1_pre",
"DisallowInward":false,
"DisallowOutward":false,
"IsRelative":false},
{
"Offset":768,
"Addr":8192,
"Length":256,
"PreLabel":"",
"DisallowInward":false,
"DisallowOutward":true,
"IsRelative":false},
{
"Offset":793,
"Addr":40960,
"Length":18,
"PreLabel":"inner2_pre",
"DisallowInward":false,
"DisallowOutward":false,
"IsRelative":false},
{
"Offset":1024,
"Addr":12288,
"Length":256,
"PreLabel":"",
"DisallowInward":true,
"DisallowOutward":false,
"IsRelative":false},
{
"Offset":1049,
"Addr":45056,
"Length":18,
"PreLabel":"inner3_pre",
"DisallowInward":false,
"DisallowOutward":false,
"IsRelative":false},
{
"Offset":1280,
"Addr":16384,
"Length":256,
"PreLabel":"",
"DisallowInward":true,
"DisallowOutward":true,
"IsRelative":false},
{
"Offset":1305,
"Addr":49152,
"Length":18,
"PreLabel":"inner4_pre",
"DisallowInward":false,
"DisallowOutward":false,
"IsRelative":false}],
"TypeHints":[{
"Low":0,
"High":0,
"Hint":"Code"},
{
"Low":256,
"High":256,
"Hint":"Code"},
{
"Low":512,
"High":512,
"Hint":"Code"},
{
"Low":1024,
"High":1024,
"Hint":"Code"},
{
"Low":1280,
"High":1280,
"Hint":"Code"}],
"StatusFlagOverrides":{
},
"Comments":{
Minor tweaks Note that address region isolation doesn't prevent explicit label references from working (add update the test to prove it). Added a note about pre-label xrefs.
2024-05-22 21:01:02 +00:00
"9":"operand label set manually"},
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
"LongComments":{
},
"Notes":{
},
"UserLabels":{
"256":{
"Label":"region1x",
"Value":4096,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"36":{
"Label":"altbnk1",
"Value":2084,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"45":{
"Label":"altbnk2",
"Value":2093,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"57":{
"Label":"done",
"Value":2105,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"512":{
"Label":"region1",
"Value":4096,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"537":{
"Label":"inner1",
"Value":36864,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"555":{
"Label":"finish1",
"Value":4139,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"768":{
"Label":"region2",
"Value":8192,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"793":{
"Label":"inner2",
"Value":40960,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"811":{
"Label":"finish2",
"Value":8235,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"1024":{
"Label":"region3",
"Value":12288,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"1049":{
"Label":"inner3",
"Value":45056,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"1067":{
"Label":"finish3",
"Value":12331,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"1280":{
"Label":"region4",
"Value":16384,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"1305":{
"Label":"inner4",
"Value":49152,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"1323":{
"Label":"finish4",
"Value":16427,
"Source":"User",
"Type":"GlobalAddr",
"LabelAnno":"None"},
"1287":{
"Label":"copy",
"Value":16391,
"Source":"User",
"Type":"NonUniqueLocalAddr",
"LabelAnno":"None"},
"1031":{
"Label":"copy",
"Value":12295,
"Source":"User",
"Type":"NonUniqueLocalAddr",
"LabelAnno":"None"},
"775":{
"Label":"copy",
"Value":8199,
"Source":"User",
"Type":"NonUniqueLocalAddr",
"LabelAnno":"None"},
"519":{
"Label":"copy",
"Value":4103,
"Source":"User",
"Type":"NonUniqueLocalAddr",
"LabelAnno":"None"},
"24":{
"Label":"self",
"Value":2072,
"Source":"User",
"Type":"GlobalAddr",
Address region isolation, part 3 (of 3) If an address resolves to a user label in an isolated region, we don't want to use it. However, we still want to try to match it to a project/platform symbol. For example, suppose the isolated code wants to reference address $1C00, which is a memory-mapped I/O location in one area, but a regular bunch of code in the other. We don't want it to map to the regular code, but we do want it to resolve to our table of platform I/O addresses. We now handle this correctly. The regression test has been updated to check this. The current implementation does a linear scan through the symbol table, but I'm hoping this is not a common situation. The reference manual has been updated to describe the new feature.
2024-05-21 21:14:32 +00:00
"LabelAnno":"None"},
"1319":{
"Label":"_checkit",
"Value":49166,
"Source":"User",
"Type":"GlobalAddr",
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
"LabelAnno":"None"}},
"OperandFormats":{
Minor tweaks Note that address region isolation doesn't prevent explicit label references from working (add update the test to prove it). Added a note about pre-label xrefs.
2024-05-22 21:01:02 +00:00
"9":{
"Length":3,
"Format":"NumericLE",
"SubFormat":"Symbol",
"SymbolRef":{
"Label":"region4",
"Part":"Low"}}},
Address region isolation, part 2 Added an address-to-offset test in the GeneratePlatformSymbolRefs() method, which sets the operand symbols for anything that lands outside the scope of the file. Because the region isolation code prevented symbols from being associated with the operands in the initial code scan, those operands were being examined here. Without the additional test, the inappropriate label associations were getting a second chance. Added "[!in]" and "[!out]" to the comment field of .addrs lines. This is only for the on-screen display and text exports, not asm gen. Bumped the project file CONTENT_VERSION. Added a regression test (20290-region-isolation). The test turned up an existing problem: pre-labels are emitted by the asm generators on their own line, but the code that puts excessively long labels on a separate line wasn't taking that into account. This has been fixed. No changes to existing regression tests, which didn't happen to use long labels.
2024-05-21 17:32:18 +00:00
"LvTables":{
},
"Visualizations":[],
"VisualizationAnimations":[],
"VisualizationSets":{
},
"RelocList":{
},
"DbrValues":{
}}
Reference in New Issue Copy Permalink