I'm still hacking away on my overengineered 6809 assembler [1] and one feature I've beem mulling over is a form of static access checking. I have byte-level access control when running tests [2] but I'm thinking that adding some form of “assemble time checking” would also be good. I've been writing code hitting the hardware of the Color Computer, and there are semantics around hardware that I don't think many languages (or even assembler) support—write only memory! As the Amiga Hardware Reference Manual [3] states (only referenced here because it's a good example of what I'm talking about):
Registers are either read-only or write-only. Reading a write-only register will trash the register. Writing a read-only register will cause unexpected results.
…
When strobing any register which responds to either a read or a write, (for example copjmp2) be sure to use a MOVE.W, not CLR.W. The CLR instruction causes a read and a clear (two access) on a 68000, but only a single access on 68020 processors. This will give different results on different processors.
The Color Computer isn't quite as finicky (although the 6809 inside it also does the “read, then write” thing with the CLR instruction), but there is still memory-mapped IO (Input/Output) that is read-only, some that is write-only, and some that has different meanings when reading and writing. And while C has some semantic support with volatile (to ensure reads and writes happen when stated) and const (to ensure the read-only nature) it still lacks a “write-only” concept. And I've never used an assembler that had “write-only” semantics either.
I'm thinking something along these lines:
org $FF40 DSK.CTRL rmb/w 1 ; write only org $FF48 DSK.CMD rmb/w 1 ; write only org $FF48 DSK.STATUS rmb/r 1 ; read only DSK.TRACK rmb 1 ; these can be read and written DSK.SECTOR rmb 1 DSK.DATA rmb 1
Here, the RMB directive just reserves a number of bytes, with a default access of “read-write.” The /W or /R designates that label as being either “write-only” or “read-only.” And if you look closely, you'll see that both DSK.CMD and DSK.STATUS are defined as the same address. It's just that writing to that address will send a command to the drive controller, while reading from that address give the current status. The only issue I have are hardware registers that can be programmed for input or output. The MC6821 [4] used in the Color Computer has such registers, and the issue I have is how to signify this change in state in a program—that at this point in the program, such-n-such address is “read-write” but afterwards, it's “write-only.”
[1] https://github.com/spc476/a09
[3] https://www.amazon.com/exec/obidos/ASIN/0201181576/conmanlaborat-20
[4] https://en.wikipedia.org/wiki/Peripheral_Interface_Adapter