New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suppress "Suspicious address expression" for 65816 direct page #194

Open
pinobatch opened this Issue Aug 6, 2015 · 10 comments

Comments

Projects
None yet
4 participants
@pinobatch

pinobatch commented Aug 6, 2015

On 65816, it is common to access several addresses in the same 256-byte page of bank $00 using direct page addressing mode. However, ca65 raises a "Range error" when using this with addresses not in the true zero page, and attempts to work around this error result in a "Suspicious address expression" warning. The docs mention neither this warning nor a way to suppress it.

.p816
VMDATA = $002118
.smart
.segment "CODE"
  sep #$20
  ; First set the direct page base
  pea linebuf & ~$FF
  pld
  ; Now try to add to direct page
  lda <linebuf      ; This is suspicious
  lda z:<linebuf    ; So is this
  lda z:linebuf     ; And this just makes a range error
  pea VMDATA & ~$FF
  pld
  sta <VMDATA       ; But this isn't
forever: jmp forever
.segment "BSS"      ; linker script puts this in $000200-$001FFF
linebuf: .res 32
@greg-king5

This comment has been minimized.

Show comment
Hide comment
@greg-king5

greg-king5 Aug 8, 2015

Contributor

Uz put this in a comment in the source code:

If the instruction has a one-byte operand, and immediate addressing is
allowed but not used, check for an operand expression in the form
<label or >label, where label is a far or absolute label. If found,
emit a warning. That warning protects against a typo, where the '#'
for the immediate operand is omitted.

You can avoid the warning by putting a "dummy" operation into the expression:

        .p816
VMDATA  := $002118
        .smart  on
.code
        sep     #%00100000
        ; First, set the direct-page base.
        pea     linebuf & ~$FF
        pld
        ; Now, use direct-page addressing.
        lda     z:<linebuf-0

        pea     VMDATA & ~$FF
        pld
        sta     <VMDATA+256     ; Note: operator precedence makes this a 16-bit address!
forever:
        jmp     forever
.bss                            ; linker script puts this in $000200-$001FFF
linebuf:
        .res    32
Contributor

greg-king5 commented Aug 8, 2015

Uz put this in a comment in the source code:

If the instruction has a one-byte operand, and immediate addressing is
allowed but not used, check for an operand expression in the form
<label or >label, where label is a far or absolute label. If found,
emit a warning. That warning protects against a typo, where the '#'
for the immediate operand is omitted.

You can avoid the warning by putting a "dummy" operation into the expression:

        .p816
VMDATA  := $002118
        .smart  on
.code
        sep     #%00100000
        ; First, set the direct-page base.
        pea     linebuf & ~$FF
        pld
        ; Now, use direct-page addressing.
        lda     z:<linebuf-0

        pea     VMDATA & ~$FF
        pld
        sta     <VMDATA+256     ; Note: operator precedence makes this a 16-bit address!
forever:
        jmp     forever
.bss                            ; linker script puts this in $000200-$001FFF
linebuf:
        .res    32
@greg-king5

This comment has been minimized.

Show comment
Hide comment
@greg-king5

greg-king5 Aug 9, 2015

Contributor

@oliverschmidt: This issue should get the "question" label.

Contributor

greg-king5 commented Aug 9, 2015

@oliverschmidt: This issue should get the "question" label.

@pinobatch

This comment has been minimized.

Show comment
Hide comment
@pinobatch

pinobatch Aug 11, 2015

Is there a label for bugs in the manual?

pinobatch commented Aug 11, 2015

Is there a label for bugs in the manual?

@oliverschmidt

This comment has been minimized.

Show comment
Hide comment
@oliverschmidt

oliverschmidt Aug 11, 2015

Collaborator

Nope - I'd say the label 'bug' with an explanation that it's about the manual should be fine - at least for now...

Collaborator

oliverschmidt commented Aug 11, 2015

Nope - I'd say the label 'bug' with an explanation that it's about the manual should be fine - at least for now...

@oliverschmidt

This comment has been minimized.

Show comment
Hide comment
@oliverschmidt

oliverschmidt Aug 25, 2015

Collaborator

If this issue is supposed to be a bug in the manual then it should be updated to explicitly state where the bug in the manual is located.

Otherwise I'd consider the question answered - and therefore close this issue.

Collaborator

oliverschmidt commented Aug 25, 2015

If this issue is supposed to be a bug in the manual then it should be updated to explicitly state where the bug in the manual is located.

Otherwise I'd consider the question answered - and therefore close this issue.

@greg-king5

This comment has been minimized.

Show comment
Hide comment
@greg-king5

greg-king5 Aug 26, 2015

Contributor

I think that each of the tool documents should have an appendix that lists that tool's messages and what they mean. (But maybe, that should be a separate issue.)

It has occurred to me that the z: prefix obviously is not a typo for #. Therefore, ca65 should not suspect lda z:<linebuf. [So ... I guess you can add the "bug" label, after all. ;-) ]

Contributor

greg-king5 commented Aug 26, 2015

I think that each of the tool documents should have an appendix that lists that tool's messages and what they mean. (But maybe, that should be a separate issue.)

It has occurred to me that the z: prefix obviously is not a typo for #. Therefore, ca65 should not suspect lda z:<linebuf. [So ... I guess you can add the "bug" label, after all. ;-) ]

@oliverschmidt oliverschmidt added the bug label Aug 26, 2015

@awjackson

This comment has been minimized.

Show comment
Hide comment
@awjackson

awjackson Jan 18, 2016

I think that "suspicious" warning should be suppressed completely when targetting the 65816. The code pattern that it's trying to protect from typos is this one:

lda #<address
sta ptr
lda #>address
sta ptr+1

And there's no reason to use that pattern in 65816 code, because it has 16-bit registers.

awjackson commented Jan 18, 2016

I think that "suspicious" warning should be suppressed completely when targetting the 65816. The code pattern that it's trying to protect from typos is this one:

lda #<address
sta ptr
lda #>address
sta ptr+1

And there's no reason to use that pattern in 65816 code, because it has 16-bit registers.

@pinobatch

This comment has been minimized.

Show comment
Hide comment
@pinobatch

pinobatch Feb 1, 2016

There's no reason for specifically that pattern in 65816 code that isn't shared with a 6502 version of the same program. But sometimes, both bytes of an address need to be written to the same MMIO port. The Super NES has a couple ports like this, such as the OAM (sprite display list) address.

sep #$20
lda #<address
sta REG_ADDR
lda #>address
sta REG_ADDR

Which has another way to do it:

lda #address
sep #$20
sta REG_ADDR
xba
sta REG_ADDR

pinobatch commented Feb 1, 2016

There's no reason for specifically that pattern in 65816 code that isn't shared with a 6502 version of the same program. But sometimes, both bytes of an address need to be written to the same MMIO port. The Super NES has a couple ports like this, such as the OAM (sprite display list) address.

sep #$20
lda #<address
sta REG_ADDR
lda #>address
sta REG_ADDR

Which has another way to do it:

lda #address
sep #$20
sta REG_ADDR
xba
sta REG_ADDR
@greg-king5

This comment has been minimized.

Show comment
Hide comment
@greg-king5

greg-king5 Feb 1, 2016

Contributor

The "safe" alternate is:

rep #$20
lda #address
sep #$20
sta REG_ADDR
xba
sta REG_ADDR
Contributor

greg-king5 commented Feb 1, 2016

The "safe" alternate is:

rep #$20
lda #address
sep #$20
sta REG_ADDR
xba
sta REG_ADDR
@pinobatch

This comment has been minimized.

Show comment
Hide comment
@pinobatch

pinobatch Aug 9, 2016

Related:

  • Bug #317 about the HuC6280, whose equivalent of the 65816's D register is fixed at $2000 rather than $0000
  • Mailing list discussion in June and July 2016 suggesting the .dpage directive, which would presumably make z: work

pinobatch commented Aug 9, 2016

Related:

  • Bug #317 about the HuC6280, whose equivalent of the 65816's D register is fixed at $2000 rather than $0000
  • Mailing list discussion in June and July 2016 suggesting the .dpage directive, which would presumably make z: work
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment