6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-07-14 05:28:55 +00:00
Code Issues Projects Releases Wiki Activity
676ab2554d
6502bench/SourceGen/SGTestData/Expected/2004-numeric-types_cc65.S

47 lines
1.4 KiB
ArmAsm
Raw Normal View History

Add junk/align directives Sometimes there's a bunch of junk in the binary that isn't used for anything. Often it's there to make things line up at the start of a page boundary. This adds a ".junk" directive that tells the disassembler that it can safely disregard the contents of a region. If the region ends on a power-of-two boundary, an alignment value can be specified. The assembly source generators will output an alignment directive when possible, a .fill directive when appropriate, and a .dense directive when all else fails. Because we're required to regenerate the original data file, it's not always possible to avoid generating a hex dump.
2019-10-19 03:28:02 +00:00
;Project file was edited to get all big-endian data types, and to have an
;incorrect .junk alignment directive.
Initial file commit
2018-09-28 17:05:11 +00:00
.setcpu "6502"
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG000"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $1000
rts
.byte $11
.word $1122
.faraddr $112233
.dword $11223344
.byte $11
.dbyt $1122
.byte $11,$22,$33
.byte $11,$22,$33,$44
.res 2,$00
.byte $80
.res 3,$00
.byte $80
.res 4,$00
.byte $80
.res 5,$00
.byte $80
.res 256,$00
.byte $80
.res 257,$cc
.byte $11
.byte $80
.byte $11,$22,$33,$44,$55,$66,$77,$88,$99,$00
.byte $80
LABEL: .byte $00,$11,$22,$33,$44,$55,$66,$77,$88,$99,$aa,$bb,$cc,$dd,$ee,$ff ;comment
.byte $00,$11,$22,$33,$44,$55,$66,$77,$88,$99,$aa,$bb,$cc,$dd,$ee,$ff
.byte $00,$11,$22,$33,$44,$55,$66,$77,$88,$99,$aa,$bb,$cc,$dd,$ee,$ff
.byte $ff,$ee,$dd,$cc,$bb,$aa,$99,$88,$77,$66,$55,$44,$33,$22,$11,$00
.byte $80
Add junk/align directives Sometimes there's a bunch of junk in the binary that isn't used for anything. Often it's there to make things line up at the start of a page boundary. This adds a ".junk" directive that tells the disassembler that it can safely disregard the contents of a region. If the region ends on a power-of-two boundary, an alignment value can be specified. The assembly source generators will output an alignment directive when possible, a .fill directive when appropriate, and a .dense directive when all else fails. Because we're required to regenerate the original data file, it's not always possible to avoid generating a hex dump.
2019-10-19 03:28:02 +00:00
.res 137,$aa
.byte $81
.res 63,$00
.byte $81
.res 31,$ab
.byte $00,$00,$00,$00,$00,$00,$00,$01
.byte $81
.byte $10,$00,$00,$00,$00,$00,$00,$00
.byte $81
.res 2,$dd ;incorrect alignment
.res 140,$00
Reference in New Issue Copy Permalink