Macros for use in expressions

[Xkeeper0]

In cases of stupid addressing like the PPU, addresses are usually written as .db $20, $00, as opposed to the usual way, due to having to write the high byte to PPUADDR first.

I wanted to do something like this:

MACRO vram addr
      .byte >addr, <addr
ENDM

SampleLabel:
;      .BYTE $20, $00, $60, $FD
      .BYTE vram($2000),  $60, $FD

However, this gives me a warning that macros aren't allowed to be used as expressions.

I got around it right now by removing the .byte:

SampleLabel:
      vram($2000), $60, $FD

...but that will only work if it's the first entry on a 'line', and feels pretty hokey.

This is probably a lot tougher than it sounds, but I at least have a workaround for it right now, so it isn't a huuuuuge issue.

[Xkeeper0]

OK, the workaround didn't work as well as I had hoped; it only works with one argument.

MACRO ppu var1 var2
  .byte >var1, <var1, var2
ENDM

SampleLabel:
  ppu($2000, $60), $ff

b.asm(52):ppu(1): Incomplete expression.

  (ppu($2000, $60)), $ff

b.asm(52): Illegal instruction.

  ppu $2000, $60, $ff

works (but the $ff is dropped, requiring a new line with ".byte $ff")

So... that didn't work out how I hoped.

[warmCabin]

+1. I've wanted this feature to bitcrunch parameters together or do "STRING"-"A"+BASE_TILE type calculations.

Here's where the error comes from, and here's were macros get expanded.

What would happen if you did:

            } else if((*p).type==MACRO) {
                needanotherpass = true;
            }

I'm not quite sure how all this fits together, but the idea is:

1. Encounter macro
2. Request another pass
3. Macro gets expanded
4. Next pass, we can work with the expanded macro

Or maybe they could be preprocessor?