teamtempest wrote:
Quote:
If the assembler is compliant with the WDC published language standards, implied instructions that have the same mnemonic as non-implied instructions (again, ROL <ADDR> vs. ROL A) never have a blank field for the operand, making it clear to both the assembler and the programmer how the instruction should be assembled. How would you reconcile that with a case where BRK might or might not have an operand?
I'm not at all sure I understand your point.
My point is that BRK, like CLC and INX, is a unique instruction, in that the mnemonic can only resolve to a single opcode ($00). All 65xx mnemonics that can resolve to more than one opcode require an operand of some sort to disambiguate the instruction. To maintain uniformity, BRK should be treated no differently. BRK takes no operand. If the programmer wishes to include a signature byte, either the assembler should include an alias for BRK that demands the entry of an operand, or a macro should be used for disambiguation.
Quote:
It seems to me it's pretty clear to both: either there's no operand (therefore one $00 byte) or there is (therefore $00+$value).
Clear to you and me, yes. However, an assembler can't determine intent. It can only react to what it encounters in the source code.
Quote:
Consider the case of WDC-recommended aliases such as BGE for BCS. Does the fact that these resolve to the same opcode matter in any practical sense?
Apples and oranges. BGE as an alias for BCS simply means two different mnemonics resolve to the same opcode ($B0) that always takes the same type of operand (a branch offset). My earlier example of using INT to assemble a BRK instruction with a signature is also a form of aliasing. In both cases, the fundamental nature of the underlying machine operation is the same. The only thing different is the way in which the source instruction is phrased.
Quote:
It is true that BRK's incrementing the PC by two before pushing it does mean that the programmer must account for that when trying to purposefully use BRK. It is not true that using a signature byte is the only way to do so. A programmer could, for example, decrement the saved PC by one as part of the service routine.
You are correct and thus have highlighted the fact that BRK itself takes no operand. The double-incrementing of the PC had to do with BRK's original purpose, which was the facilitation of PROM patching. However, BRK can also be used to transfer program control to a supervisor function, with the signature byte indicating to the supervisor the desired operation—a procedure analogous to the
INT 0x21 sequence used to call services in MS-DOS. The latter application would be a case where programmer intent would demand the use of the signature byte.
As an aside, the W65C816S makes using the
INT <INTNUM> method of calling system services trivial, thanks to the stack relative instructions.
Quote:
So I would be reluctant to require a signature byte.
So would I, as mentioned a few posts ago. Continue to treat the BRK mnemonic as an instruction that takes no operand.
Quote:
What I probably will do, though, is update the documentation to make special note of BRK and to offer an example INT <sig> macro to those who want to make sure there always is one. Something like this, perhaps:
Code:
.macro INT, ?sig=""
.if "?sig"
BRK ?sig
.else
.error "Signature byte required"
.endif
.endm
Gee, where did that idea come from?
You'd want to include a test to verify that the
?sig parameter is in the range $00-$FF.
Quote:
An alternative would be to allow a macro named BRK to override the instruction named BRK...
That I wouldn't do. Aside from the possible confusion it would cause, it wouldn't work with an assembler that prohibits replacing a standard 65xx mnemonic with a macro (the Kowalski simulator's assembler is in that category).