Suppress "Suspicious address expression" for 65816 direct page

[pinobatch]

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]

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]

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

[pinobatch]

Is there a label for bugs in the manual?

[oliverschmidt]

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

[oliverschmidt]

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]

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. ;-) ]

[awjackson]

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]

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]

The "safe" alternate is:

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

[pinobatch]

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

[oliverschmidt]

I don't see any open question here...