6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-03 05:49:48 +00:00
Code Issues Projects Releases Wiki Activity
4e5c34f457
6502bench/SourceGen/SGTestData/Expected/20182-extension-scripts_acme.S

127 lines
2.4 KiB
ArmAsm
Raw Normal View History

Expand the set of things SetInlineDataFormat accepts Extension scripts (a/k/a "plugins") can now apply any data format supported by FormatDescriptor to inline data. In particular, it can now handle variable-length inline strings. The code analyzer verifies the string structure (e.g. null-terminated strings have exactly one null byte, at the very end). Added PluginException to carry an exception back to the plugin code, for occasions when they're doing something so wrong that we just want to smack them. Added test 2022-extension-scripts to exercise the feature.
2019-10-06 02:51:34 +00:00
!cpu 65816
PrintInlineL1String = $011000
PrintInlineL2String = $012000
PrintInlineDciString = $013000
ORG rework, part 1 This is the first step toward changing the address region map from a linear list to a hierarchy. See issue #107 for the plan. The AddressMap class has been rewritten to support the new approach. The rest of the project has been updated to conform to the new API, but feature-wise is unchanged. While the map class supports nested regions with explicit lengths, the rest of the application still assumes a series of non-overlapping regions with "floating" lengths. The Set Address dialog is currently non-functional. All of the output for cc65 changed because generation of segment comments has been removed. Some of the output for ACME changed as well, because we no longer follow "* = addr" with a redundant pseudopc statement. ACME and 65tass have similar approaches to placing things in memory, and so now have similar implementations.
2021-09-17 00:02:19 +00:00
* = $1000
Expand the set of things SetInlineDataFormat accepts Extension scripts (a/k/a "plugins") can now apply any data format supported by FormatDescriptor to inline data. In particular, it can now handle variable-length inline strings. The code analyzer verifies the string structure (e.g. null-terminated strings have exactly one null byte, at the very end). Added PluginException to carry an exception back to the plugin code, for occasions when they're doing something so wrong that we just want to smack them. Added test 2022-extension-scripts to exercise the feature.
2019-10-06 02:51:34 +00:00
!as
!rs
clc
xce
sep #$30
jsr PrintInline8String
!text "01234567"
jsr PrintInlineRev8String
!text "76543210"
jsr PrintInlineNullString
!text "null-term string",$00
jsl PrintInlineL1String
!text $14,"string with length/1"
jsl PrintInlineL2String
!text $14,$00,"string with length/2"
jsl PrintInlineDciString
!text "DCI strin",$e7
Fix bug in inline JSR/JSL no-continue handling JSR/JSL calls with inline data have the option of reporting that they don't continue, which causes the code analyzer to treat them as JMPs instead. There was a bug that was causing the no-continue flag to be lost in certain circumstances. The code now explicitly records the plugin's response in an Anattrib flag. Test 2022-extension-scripts has been updated with a test case that exercises this situation.
2020-05-09 00:41:26 +00:00
jsr L1800
jsr L184F
jsr L1848
Optionally treat BRKs as two-byte instructions Early data sheets listed BRK as one byte, but RTI after a BRK skips the following byte, effectively making BRK a 2-byte instruction. Sometimes, such as when diassembling Apple /// SOS code, it's handy to treat it that way explicitly. This change makes two-byte BRKs optional, controlled by a checkbox in the project settings. In the system definitions it defaults to true for Apple ///, false for all others. ACME doesn't allow BRK to have an arg, and cc65 only allows it for 65816 code (?), so it's emitted as a hex blob for those assemblers. Anyone wishing to target those assemblers should stick to 1-byte mode. Extension scripts have to switch between formatting one byte of inline data and formatting an instruction with a one-byte operand. A helper function has been added to the plugin Util class. To get some regression test coverage, 2022-extension-scripts has been configured to use two-byte BRK. Also, added/corrected some SOS constants. See also issue #44.
2019-10-09 21:55:56 +00:00
!byte $00,$01
Exercise address-to-offset function in plugin Also exercise various formatting options. Also, fix a bug where the code that applies project/platform symbols to numeric references was ignoring inline data items.
2019-10-07 21:21:26 +00:00
!word data01
Optionally treat BRKs as two-byte instructions Early data sheets listed BRK as one byte, but RTI after a BRK skips the following byte, effectively making BRK a 2-byte instruction. Sometimes, such as when diassembling Apple /// SOS code, it's handy to treat it that way explicitly. This change makes two-byte BRKs optional, controlled by a checkbox in the project settings. In the system definitions it defaults to true for Apple ///, false for all others. ACME doesn't allow BRK to have an arg, and cc65 only allows it for 65816 code (?), so it's emitted as a hex blob for those assemblers. Anyone wishing to target those assemblers should stick to 1-byte mode. Extension scripts have to switch between formatting one byte of inline data and formatting an instruction with a one-byte operand. A helper function has been added to the plugin Util class. To get some regression test coverage, 2022-extension-scripts has been configured to use two-byte BRK. Also, added/corrected some SOS constants. See also issue #44.
2019-10-09 21:55:56 +00:00
!byte $00,$02
Exercise address-to-offset function in plugin Also exercise various formatting options. Also, fix a bug where the code that applies project/platform symbols to numeric references was ignoring inline data items.
2019-10-07 21:21:26 +00:00
!word data02
Correctly handle embedded instruction edge case This began with a change to support "BRK <operand>" in cc65. The assembler only supports this for 65816 projects, so we detect that and enable it when available. While fiddling with some test code an assertion fired. This revealed a minor issue in the code analyzer: when overwriting inline data with instructions, we weren't resetting the format descriptor. The code that exercises it, which requires two-byte BRKs and an inline BRK handler in an extension script, has been added to test 2022-extension-scripts. The new regression test revealed a flaw in the 64tass code generator's character encoding scanner that caused it to hang. Fixed.
2019-10-19 23:23:42 +00:00
nop
jsr L1085
!byte $24
L1085 !byte $a9
!byte $00
sta $ff
!byte $ea
Fix bug in inline JSR/JSL no-continue handling JSR/JSL calls with inline data have the option of reporting that they don't continue, which causes the code analyzer to treat them as JMPs instead. There was a bug that was causing the no-continue flag to be lost in certain circumstances. The code now explicitly records the plugin's response in an Anattrib flag. Test 2022-extension-scripts has been updated with a test case that exercises this situation.
2020-05-09 00:41:26 +00:00
jmp Next1
Expand the set of things SetInlineDataFormat accepts Extension scripts (a/k/a "plugins") can now apply any data format supported by FormatDescriptor to inline data. In particular, it can now handle variable-length inline strings. The code analyzer verifies the string structure (e.g. null-terminated strings have exactly one null byte, at the very end). Added PluginException to carry an exception back to the plugin code, for occasions when they're doing something so wrong that we just want to smack them. Added test 2022-extension-scripts to exercise the feature.
2019-10-06 02:51:34 +00:00
PrintInline8String rts
PrintInlineRev8String rts
PrintInlineNullString rts
Exercise address-to-offset function in plugin Also exercise various formatting options. Also, fix a bug where the code that applies project/platform symbols to numeric references was ignoring inline data items.
2019-10-07 21:21:26 +00:00
data01 !word 4386
!byte $33,$44
!32 $88776655
!byte $99,$88,$77,$66
!byte 'f'
!byte 'F' | $80
!byte $40
!byte $c1
!byte $42
!byte $c3
!byte $44
!byte $c5
!byte $46
!byte $c7
!24 PrintInlineL2String
!word data02
!byte $80
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
data02 !word @data03
Exercise address-to-offset function in plugin Also exercise various formatting options. Also, fix a bug where the code that applies project/platform symbols to numeric references was ignoring inline data items.
2019-10-07 21:21:26 +00:00
!byte $80
!xor $80 {
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
@data03 !text "AllEight"
Exercise address-to-offset function in plugin Also exercise various formatting options. Also, fix a bug where the code that applies project/platform symbols to numeric references was ignoring inline data items.
2019-10-07 21:21:26 +00:00
}
Fix bug in inline JSR/JSL no-continue handling JSR/JSL calls with inline data have the option of reporting that they don't continue, which causes the code analyzer to treat them as JMPs instead. There was a bug that was causing the no-continue flag to be lost in certain circumstances. The code now explicitly records the plugin's response in an Anattrib flag. Test 2022-extension-scripts has been updated with a test case that exercises this situation.
2020-05-09 00:41:26 +00:00
NoCont pla ;split across address change
pla
rts
L10BA jsr NoCont
!byte $00
!byte $80
L10BF jsr NoCont
!byte $00
!byte $80
Next1 jsr L10BA
jsr @L10CF
clc
jsr L10BF
rts
@L10CF sec
jsr L10BF
Mark flags as indeterminate for inline BRK We weren't altering the status flags after a BRK because of the assumption that a BRK was a crash. For an inline BRK, such as a SOS call, execution continues. We need to mark NVZC indeterminate or we may incorrectly handle conditional branches that follow. The BRK instruction now uses the same flag updater as JSR, since it's effectively a subroutine call to unknown code. If execution doesn't continue across the BRK then the flags don't matter. Updated 20182-extension-scripts to exercise this.
2020-08-22 15:56:38 +00:00
clc
!byte $00,$02
!word data02
bcc @L10DE
bcs @L10DE
!byte $00
!byte $80
@L10DE rts
Fix bug in inline JSR/JSL no-continue handling JSR/JSL calls with inline data have the option of reporting that they don't continue, which causes the code analyzer to treat them as JMPs instead. There was a bug that was causing the no-continue flag to be lost in certain circumstances. The code now explicitly records the plugin's response in an Anattrib flag. Test 2022-extension-scripts has been updated with a test case that exercises this situation.
2020-05-09 00:41:26 +00:00
Mark flags as indeterminate for inline BRK We weren't altering the status flags after a BRK because of the assumption that a BRK was a crash. For an inline BRK, such as a SOS call, execution continues. We need to mark NVZC indeterminate or we may incorrectly handle conditional branches that follow. The BRK instruction now uses the same flag updater as JSR, since it's effectively a subroutine call to unknown code. If execution doesn't continue across the BRK then the flags don't matter. Updated 20182-extension-scripts to exercise this.
2020-08-22 15:56:38 +00:00
!fill 289,$00
Fix bug in inline JSR/JSL no-continue handling JSR/JSL calls with inline data have the option of reporting that they don't continue, which causes the code analyzer to treat them as JMPs instead. There was a bug that was causing the no-continue flag to be lost in certain circumstances. The code now explicitly records the plugin's response in an Anattrib flag. Test 2022-extension-scripts has been updated with a test case that exercises this situation.
2020-05-09 00:41:26 +00:00
!pseudopc $1800 {
L1800 jsr PrintInlineNullString
per $8778
Expand the set of things SetInlineDataFormat accepts Extension scripts (a/k/a "plugins") can now apply any data format supported by FormatDescriptor to inline data. In particular, it can now handle variable-length inline strings. The code analyzer verifies the string structure (e.g. null-terminated strings have exactly one null byte, at the very end). Added PluginException to carry an exception back to the plugin code, for occasions when they're doing something so wrong that we just want to smack them. Added test 2022-extension-scripts to exercise the feature.
2019-10-06 02:51:34 +00:00
rtl
!byte $65
!byte $6e
!byte $20
!byte $01
ORG rework, part 3 Split ".org" into ".arstart" and ".arend" (address range start/end). Address range ends are now shown in the code list view, and the pseudo-op can be edited in app settings. Address range starts are now shown after notes and long comments, rather than before, which brings the on-screen display in sync with generated code. Reworked the address range editor UI to include the new features. The implementation is fully broken. More changes to the AddressMap API, putting the resolved region length into a separate ActualLength field. Added FindRegion(). Renamed some things. Code generation changed slightly: the blank line before a region-end line now comes after it, and ACME's "} ;!pseudopc" is now just "}". This required minor updates to some of the regression test results.
2021-09-22 21:39:39 +00:00
}
Fix bug in inline JSR/JSL no-continue handling JSR/JSL calls with inline data have the option of reporting that they don't continue, which causes the code analyzer to treat them as JMPs instead. There was a bug that was causing the no-continue flag to be lost in certain circumstances. The code now explicitly records the plugin's response in an Anattrib flag. Test 2022-extension-scripts has been updated with a test case that exercises this situation.
2020-05-09 00:41:26 +00:00
!pseudopc $1840 {
Expand the set of things SetInlineDataFormat accepts Extension scripts (a/k/a "plugins") can now apply any data format supported by FormatDescriptor to inline data. In particular, it can now handle variable-length inline strings. The code analyzer verifies the string structure (e.g. null-terminated strings have exactly one null byte, at the very end). Added PluginException to carry an exception back to the plugin code, for occasions when they're doing something so wrong that we just want to smack them. Added test 2022-extension-scripts to exercise the feature.
2019-10-06 02:51:34 +00:00
!text "string"
!byte $00
!byte $60
Fix bug in inline JSR/JSL no-continue handling JSR/JSL calls with inline data have the option of reporting that they don't continue, which causes the code analyzer to treat them as JMPs instead. There was a bug that was causing the no-continue flag to be lost in certain circumstances. The code now explicitly records the plugin's response in an Anattrib flag. Test 2022-extension-scripts has been updated with a test case that exercises this situation.
2020-05-09 00:41:26 +00:00
L1848 jsl PrintInlineL2String
Expand the set of things SetInlineDataFormat accepts Extension scripts (a/k/a "plugins") can now apply any data format supported by FormatDescriptor to inline data. In particular, it can now handle variable-length inline strings. The code analyzer verifies the string structure (e.g. null-terminated strings have exactly one null byte, at the very end). Added PluginException to carry an exception back to the plugin code, for occasions when they're doing something so wrong that we just want to smack them. Added test 2022-extension-scripts to exercise the feature.
2019-10-06 02:51:34 +00:00
asl
Optionally treat BRKs as two-byte instructions Early data sheets listed BRK as one byte, but RTI after a BRK skips the following byte, effectively making BRK a 2-byte instruction. Sometimes, such as when diassembling Apple /// SOS code, it's handy to treat it that way explicitly. This change makes two-byte BRKs optional, controlled by a checkbox in the project settings. In the system definitions it defaults to true for Apple ///, false for all others. ACME doesn't allow BRK to have an arg, and cc65 only allows it for 65816 code (?), so it's emitted as a hex blob for those assemblers. Anyone wishing to target those assemblers should stick to 1-byte mode. Extension scripts have to switch between formatting one byte of inline data and formatting an instruction with a one-byte operand. A helper function has been added to the plugin Util class. To get some regression test coverage, 2022-extension-scripts has been configured to use two-byte BRK. Also, added/corrected some SOS constants. See also issue #44.
2019-10-09 21:55:56 +00:00
!byte $00,$60
Expand the set of things SetInlineDataFormat accepts Extension scripts (a/k/a "plugins") can now apply any data format supported by FormatDescriptor to inline data. In particular, it can now handle variable-length inline strings. The code analyzer verifies the string structure (e.g. null-terminated strings have exactly one null byte, at the very end). Added PluginException to carry an exception back to the plugin code, for occasions when they're doing something so wrong that we just want to smack them. Added test 2022-extension-scripts to exercise the feature.
2019-10-06 02:51:34 +00:00
Fix bug in inline JSR/JSL no-continue handling JSR/JSL calls with inline data have the option of reporting that they don't continue, which causes the code analyzer to treat them as JMPs instead. There was a bug that was causing the no-continue flag to be lost in certain circumstances. The code now explicitly records the plugin's response in an Anattrib flag. Test 2022-extension-scripts has been updated with a test case that exercises this situation.
2020-05-09 00:41:26 +00:00
L184F jsr PrintInlineNullString
Expand the set of things SetInlineDataFormat accepts Extension scripts (a/k/a "plugins") can now apply any data format supported by FormatDescriptor to inline data. In particular, it can now handle variable-length inline strings. The code analyzer verifies the string structure (e.g. null-terminated strings have exactly one null byte, at the very end). Added PluginException to carry an exception back to the plugin code, for occasions when they're doing something so wrong that we just want to smack them. Added test 2022-extension-scripts to exercise the feature.
2019-10-06 02:51:34 +00:00
adc $6e
!byte $64
ORG rework, part 3 Split ".org" into ".arstart" and ".arend" (address range start/end). Address range ends are now shown in the code list view, and the pseudo-op can be edited in app settings. Address range starts are now shown after notes and long comments, rather than before, which brings the on-screen display in sync with generated code. Reworked the address range editor UI to include the new features. The implementation is fully broken. More changes to the AddressMap API, putting the resolved region length into a separate ActualLength field. Added FindRegion(). Renamed some things. Code generation changed slightly: the blank line before a region-end line now comes after it, and ACME's "} ;!pseudopc" is now just "}". This required minor updates to some of the regression test results.
2021-09-22 21:39:39 +00:00
}
Reference in New Issue Copy Permalink