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
d2326c389f
6502bench/SourceGen/SGTestData/Expected/20022-operand-formats_64tass.S

34 lines
777 B
ArmAsm
Raw Normal View History

Split 2002x-operand-formats test My original goal was to add a sign-extended decimal format, but that turned out to be awkward. It works for data items and instructions with immediate operands (e.g. "LDA #-1"), but is either wrong or useless for address operands, since most assemblers treat integers as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF, which is not useful unless your asm is doing an implicit mod.) There's also a bit of variability in how assemblers treat negative values, so I'm shelving the idea for now. I'm keeping the updated tests, which are now split into 6502 / 65816 parts. Also, updated the formatter to output all decimal values as unsigned. Most assemblers were fine with negative values, but 64tass .dword insists on positive. Rather than make the opcode conditional on the value's range, we now just always output unsigned decimal, which all current assemblers accept.
2020-06-09 00:47:26 +00:00
;Project file was edited to force ASCII formatting for some operands.
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
.cpu "65816"
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_hiascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.cdef $20,$7e,$a0
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
Change the way ASCII is handled for 64tass The documentation for 64tass says you're required to pass "--ascii" when the source file is ASCII (as opposed to PETSCII). We were ignoring this, but it turns out that everything works a bit better if we don't. So we now pass "--ascii" on the command line, and add a two-line character encoding definition to every file that is generated with ASCII as the default encoding. The sg_petscii and sg_screen encodings go away, as PETSCII is now the default, and we can use the built-in "screen" encoding.
2019-08-20 18:21:30 +00:00
.cdef $20,$7e,$20
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
* = $1000
.as
.xs
clc
xce
Split 2002x-operand-formats test My original goal was to add a sign-extended decimal format, but that turned out to be awkward. It works for data items and instructions with immediate operands (e.g. "LDA #-1"), but is either wrong or useless for address operands, since most assemblers treat integers as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF, which is not useful unless your asm is doing an implicit mod.) There's also a bit of variability in how assemblers treat negative values, so I'm shelving the idea for now. I'm keeping the updated tests, which are now split into 6502 / 65816 parts. Also, updated the formatter to output all decimal values as unsigned. Most assemblers were fine with negative values, but 64tass .dword insists on positive. Rather than make the opcode conditional on the value's range, we now just always output unsigned decimal, which all current assemblers accept.
2020-06-09 00:47:26 +00:00
rep #$30
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
.al
.xl
Split 2002x-operand-formats test My original goal was to add a sign-extended decimal format, but that turned out to be awkward. It works for data items and instructions with immediate operands (e.g. "LDA #-1"), but is either wrong or useless for address operands, since most assemblers treat integers as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF, which is not useful unless your asm is doing an implicit mod.) There's also a bit of variability in how assemblers treat negative values, so I'm shelving the idea for now. I'm keeping the updated tests, which are now split into 6502 / 65816 parts. Also, updated the formatter to output all decimal values as unsigned. Most assemblers were fine with negative values, but 64tass .dword insists on positive. Rather than make the opcode conditional on the value's range, we now just always output unsigned decimal, which all current assemblers accept.
2020-06-09 00:47:26 +00:00
lda #$1234
lda #4660
lda #4660
lda #%0001001000110100
lda #$fffe
lda #65534
lda #65534
lda #%1111111111111110
lda $fffefd
lda 16776957
lda 16776957
lda %111111111111111011111101
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
lda #'h'
Replace character operand output method The previous code output a character in single-quotes if it was standard ASCII, double-quotes if high ASCII, or hex if it was neither of those. If a flag was set, high ASCII would also be output as hex. The new system takes the character value and an encoding identifier. The identifier selects the character converter and delimiter pattern, and puts the two together to generate the operand. While doing this I realized that I could trivially support high ASCII character arguments in all assemblers by setting the delimiter pattern to "'#' | $80". In FormatDescriptor, I had previously renamed the "Ascii" sub-type "LowAscii" so it wouldn't be confused, but I dislike filling the project file with "LowAscii" when "Ascii" is more accurate and less confusing. So I switched it back, and we now check the project file version number when deciding what to do with an ASCII item. The CharEncoding tests/converters were also renamed. Moved the default delimiter patterns to the string table. Widened the delimiter pattern input fields slightly. Added a read- only TextBox with assorted non-typewriter quotes and things so people have something to copy text from.
2019-08-12 00:59:20 +00:00
lda #'H' | $80
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
lda #$6868
Split 2002x-operand-formats test My original goal was to add a sign-extended decimal format, but that turned out to be awkward. It works for data items and instructions with immediate operands (e.g. "LDA #-1"), but is either wrong or useless for address operands, since most assemblers treat integers as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF, which is not useful unless your asm is doing an implicit mod.) There's also a bit of variability in how assemblers treat negative values, so I'm shelving the idea for now. I'm keeping the updated tests, which are now split into 6502 / 65816 parts. Also, updated the formatter to output all decimal values as unsigned. Most assemblers were fine with negative values, but 64tass .dword insists on positive. Rather than make the opcode conditional on the value's range, we now just always output unsigned decimal, which all current assemblers accept.
2020-06-09 00:47:26 +00:00
lda @l'h'
lda @l'H' | $80
Progress toward 64tass support Most tests pass, but 2007-labels-and-symbols fails because the expressions recognized by 64tass don't match up with either of the other assemblers. This is currently using a workaround for the local label syntax. 64tass uses '_' as the prefix, which is unfortunate since SourceGen explicitly allowed underscores in labels. (So does 64tass for that matter, but it treats labels specially when the '_' comes first.) We will need to rename any non-local user labels that start with '_'. (issue #16)
2018-10-23 23:06:29 +00:00
rts
Reference in New Issue Copy Permalink