Implement WORD() function

[Rangi42]

This returns the low 16 bits of a label or constant, as discussed in #rgbds.

make develop does not give any new warnings, only the same ones as before:

src/asm/asmy.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
include/extern/getopt.h:29:14: error: ‘optarg’ redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes]
include/extern/getopt.h:30:12: error: ‘optind’ redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes]
include/extern/getopt.h:30:20: error: ‘opterr’ redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes]
include/extern/getopt.h:30:28: error: ‘optopt’ redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes]
include/extern/getopt.h:30:36: error: ‘optreset’ redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes]

make checkpatch does not give any warnings.

Using WORD(-X) in place of $10000 - X in pokecrystal succeeds to make compare.

[pinobatch]

For comparison, ca65 (and hence ca83) has these five functions:

• .lobyte(x) or <x to extract bits 7-0
• .hibyte(x) or >x to extract bits 15-8
• .bankbyte(x) or ^x to extract bits 23-16
• .loword(x) to extract bits 15-0
• .hiword(x) to extract bits 31-16

N.B.: The .bankbyte function in ca65 is so called to reflect terminology used in WDC's documentation for the 65C816 CPU. (This CPU is used alongside SM83 in a Super NES with Super Game Boy.) It's not to be confused with .bank(x) which is used with mappers.

[Rangi42]

@ISSOtm Would LOWWORD and HIGHWORD, or LOWORD and HIWORD, be preferable to only WORD? (A high-word function could be useful for those 32-bit middle-endian values you mentioned.)

[ISSOtm]

Given that we have never needed WORD so far, I don't think they're useful as built-ins. (In fact, I'm thinking WORD might be better left to #201; HIGH and LOW having special meaning with regs, they make more sense as built-ins)

[Rangi42]

I think the dw WORD(-Label) use case justifies a built-in WORD function, to replace instances of Label & $ffff or $10000 - Label. With user-defined functions, projects would end up each defining the same function if it doesn't already exist. (IIRC you were considering built-in dbw, dwb, dba, dab, and/or dn for similar reasons?)

[ISSOtm]

No, only something that would make defining them easier.

Projects defining the same functions, to me, seems akin to hardware.inc; the community could create a rgblib.inc file, for example, containing wildely-agreed upon macros, for example.

[Rangi42]

Shall I close this then?

[ISSOtm]

Let's keep it around, if for any reason user-defined functions wind up not being implemented.

[Rangi42]

Superseded by a PR from a feature branch, #561.