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
8c053c29f2
6502bench/SourceGen/SGTestData/Expected/20200-ui-edge-cases_acme.S

26 lines
531 B
ArmAsm
Raw Normal View History

Correct handling of no-op .ORG statements These were being overlooked because they didn't actually cause anything to happen (a no-op .ORG sets the address to what it would already have been). The assembly source generator works in a way that causes them to be skipped, so everybody was happy. This seemed like the sort of thing that was likely to cause problems down the road, however, so we now split regions correctly when a no-op .ORG is encountered. This affects the uncategorized data analyzer and selection grouping. This changed the behavior of the 2004-numeric-types test, which was visibly weird in the UI but generated correct output. Added the 2024-ui-edge-cases test to provide a place to exercise edge cases when testing the UI by hand. It has some value for the automated regression test, so it's included there. Also, changed the AddressMapEntry objects to be immutable. This is handy when passing lists of them around.
2020-02-28 22:43:03 +00:00
!cpu 6502
Fix ACME code gen "overflow" ACME has a "real" PC and a "pseudo" PC. The "real" PC determines the initial position in a 64KB buffer used to hold assembler output. If the amount of code generated runs off the end, the assembler fails with "produced too much code". The source code generator in SourceGen was outputting a "real" PC for the first address range and "psuedo" PCs for any address ranges that followed. This produced nice results for code with a single range, but caused problems for multi-range sources if the initial range was high in memory and a later range was lower in memory. While the assembler isn't actually generating more than 64KB of code, ACME's buffer management was detecting an overflow. Now, if a source file has multiple address ranges, we set the "real" PC to $0000 and use a "pseudo" PC for all ranges. Output for projects with a single address range is unmodified.
2020-05-14 23:37:33 +00:00
* = $0000
!pseudopc $2000 {
Correct handling of no-op .ORG statements These were being overlooked because they didn't actually cause anything to happen (a no-op .ORG sets the address to what it would already have been). The assembly source generator works in a way that causes them to be skipped, so everybody was happy. This seemed like the sort of thing that was likely to cause problems down the road, however, so we now split regions correctly when a no-op .ORG is encountered. This affects the uncategorized data analyzer and selection grouping. This changed the behavior of the 2004-numeric-types test, which was visibly weird in the UI but generated correct output. Added the 2024-ui-edge-cases test to provide a place to exercise edge cases when testing the UI by hand. It has some value for the automated regression test, so it's included there. Also, changed the AddressMapEntry objects to be immutable. This is handy when passing lists of them around.
2020-02-28 22:43:03 +00:00
jmp L2100
!text "hello, " ;string should be split by no-op addr change
Fix ACME code gen "overflow" ACME has a "real" PC and a "pseudo" PC. The "real" PC determines the initial position in a 64KB buffer used to hold assembler output. If the amount of code generated runs off the end, the assembler fails with "produced too much code". The source code generator in SourceGen was outputting a "real" PC for the first address range and "psuedo" PCs for any address ranges that followed. This produced nice results for code with a single range, but caused problems for multi-range sources if the initial range was high in memory and a later range was lower in memory. While the assembler isn't actually generating more than 64KB of code, ACME's buffer management was detecting an overflow. Now, if a source file has multiple address ranges, we set the "real" PC to $0000 and use a "pseudo" PC for all ranges. Output for projects with a single address range is unmodified.
2020-05-14 23:37:33 +00:00
} ;!pseudopc
Correct handling of no-op .ORG statements These were being overlooked because they didn't actually cause anything to happen (a no-op .ORG sets the address to what it would already have been). The assembly source generator works in a way that causes them to be skipped, so everybody was happy. This seemed like the sort of thing that was likely to cause problems down the road, however, so we now split regions correctly when a no-op .ORG is encountered. This affects the uncategorized data analyzer and selection grouping. This changed the behavior of the 2004-numeric-types test, which was visibly weird in the UI but generated correct output. Added the 2024-ui-edge-cases test to provide a place to exercise edge cases when testing the UI by hand. It has some value for the automated regression test, so it's included there. Also, changed the AddressMapEntry objects to be immutable. This is handy when passing lists of them around.
2020-02-28 22:43:03 +00:00
!pseudopc $200a {
!text "world"
!byte $80
} ;!pseudopc
!pseudopc $2100 {
L2100 lda #$00
sta addr1-1 ;edit this operand
sta addr1
sta addr1+1
jmp L2121
!text "testing stuff."
addr1 !text "!?---"
L2121 rts
} ;!pseudopc
Reference in New Issue Copy Permalink