Closed gorsat closed 3 months ago
Currently SETDP expects a 16-bit value and uses the MSB as the page number. I did it this way so that address labels can be used directly: SETDP MYLABEL
This may cause some confusion since in reality DP is an 8-bit register, so assuming that SETDP takes a byte value is reasonable.
I think I'll modify the behavior such that if SETDP is given an 8-bit value, then that value will be interpreted as a page number whereas 16-bit values will behave just as they do now.
SETDP now works with both 8-bit and 16-bit args.
SETDP xx
means DP is set to xxSETDP mmnn
means DP is set to mm (it's a syntax error if nn != 00)SETDP TABLE
, the label must be page-aligned or an error will be raised. SETDP <expression>
is not yet supportedFWIW, I think it's fairly common to see SETDP used with a label in an integer divide or right shift expression; e.g.
setdp VARIABLES / 256
I like your approach of interpreting the effective size of the operand 👍, but just wanted to mention that support for an operand expression would be useful at some point.
I also wonder whether a warning might be more appropriate than an error when the label isn't page aligned. Might I not write code that accounts for the position of my data in the target page, even when the label I use to "pin" the page number isn't page aligned? Just a thought...
Simple expressions are now supported so SETDP VARIABLES/256
should work. (Note: the expression can't contain spaces.) This was an easy fix.
Regarding args that aren't page aligned: I feel that the support for expressions provides everything needed here. If you have a label like this:
MY_LABEL ORG $1234
and you want MY_LABEL to be on the direct page then you can just
SETDP MY_LABEL/256
But explicitly telling the assembler to set direct page to a non-page-aligned value feels like an error to me. I would do that accidentally and I'd want it to fail. Granted, that's a subjective take, and probably influenced by rust rapping my knuckles all the time :-)
At any rate, splitting the validation code into success/warn/fail (instead of just success/fail) is more investment than I'd like to make in this since I think expressions gets us all the way there. I'll make sure to document this example (issue #8).
I agree -- if you support SETDP expressions then there's no reason not to throw an error if the expression evaluates to more than 255 and the least significant byte isn't zero.
Looks like we're good for now on this front.
Add SETDP and review/update and/or remove logic that attempts to automatically use direct mode.