Currently, if an func/var/const is declared inside an bank that has 24-bit address, Wiz will discard the upper byte of the address, except if the address uses far addressing. While generally okay for subroutines and data that references each other in the same bank, this can occasionally cause issues when stuff exists in other banks than the one being used.
On 65816, the data_bank and program_bank can be both changed independently, effectively effectively creating two different 64K address spaces for the code and the data. An executing subroutine might not be able to access a constant if it assumes it lives in the same bank, and the compiler won't help you right now. As a result, you may be presented with some fun bugs as you wonder why some data you're trying to read defined next to your subroutine isn't there -- eg. the data bank is 0x00, but the program bank is 0x7E!
There's an open issue to allow specifying the assumed values of the direct page, data bank and program bank. This should probably be done, but also, in the absense of such an explicit assumption, we should probably assume the program+data bank are equal to address of the bank whose contents are being compiled.
Next, we should make it possible to either:
1) automatically generate far addresses for any values that are outside the currently assumed bank-address, but optimize to absolute for ones that fit, Do a similar check for direct-page / zero-page.
2) make it an error to reference something outside the active bank-address. (??? maybe this can be done with 3 below)
3) allow explicit qualifiers to specify the exact addresing mode of instruction if the implicit ("best match") one is not wanted -- eg. force zero page and enforce error-check it by a qualifier, force absolute sized operand instead of zero-page, force far addressing instead of absolute.
This "is the same bank address" determination should look at only the significant part of the far address (eg. the top 8 bits of a 24-bit far address, that would be when 16-bit absolute.) Otherwise, we might need proper way to define a full memory map for the system, and this quickly grows beyond the scope of the issue I wanted to cover.
Currently, if an
func/var/constis declared inside an bank that has 24-bit address, Wiz will discard the upper byte of the address, except if the address usesfaraddressing. While generally okay for subroutines and data that references each other in the same bank, this can occasionally cause issues when stuff exists in other banks than the one being used.On 65816, the
data_bankandprogram_bankcan be both changed independently, effectively effectively creating two different 64K address spaces for the code and the data. An executing subroutine might not be able to access a constant if it assumes it lives in the same bank, and the compiler won't help you right now. As a result, you may be presented with some fun bugs as you wonder why some data you're trying to read defined next to your subroutine isn't there -- eg. the data bank is 0x00, but the program bank is 0x7E!There's an open issue to allow specifying the assumed values of the direct page, data bank and program bank. This should probably be done, but also, in the absense of such an explicit assumption, we should probably assume the program+data bank are equal to address of the bank whose contents are being compiled.
Next, we should make it possible to either:
1) automatically generate far addresses for any values that are outside the currently assumed bank-address, but optimize to absolute for ones that fit, Do a similar check for direct-page / zero-page. 2) make it an error to reference something outside the active bank-address. (??? maybe this can be done with 3 below) 3) allow explicit qualifiers to specify the exact addresing mode of instruction if the implicit ("best match") one is not wanted -- eg. force zero page and enforce error-check it by a qualifier, force absolute sized operand instead of zero-page, force far addressing instead of absolute.
This "is the same bank address" determination should look at only the significant part of the far address (eg. the top 8 bits of a 24-bit far address, that would be when 16-bit absolute.) Otherwise, we might need proper way to define a full memory map for the system, and this quickly grows beyond the scope of the issue I wanted to cover.