I'm working on an embeddable 6502/65c02 assembler. While studying the instruction sets, I discovered that the BRK instruction is, in some ways, a 1-byte instruction, but in other ways it is a 2-byte instruction.

As far as I can see, the "obviously correct" interpretation is that it is a 2-byte instruction with an immediate operand that is ignored. Unfortunately, this seems to be at odds with most(?) references, and probably also most(?) existing assemblers.

My question: has any assemblers treated the BRK instruction as a 2-byte instruction?

BRK is a two byte instruction in the sense that when the PC is pushed it is double-incremented. Most assemblers either ignore that feature or give you the option to assemble BRK with a following ("signature") byte, such as $EA (NOP)—the Kowalski 6502 simulator falls into the latter category.

Similarly with the W65C816S, the COP instruction double-increments the PC before pushing it to the stack, so its behavior is like that of BRK. However, the W65C816S data sheet lists COP as a two byte instruction, and my assembler enforces that.

When I wrote the M/L monitor for my W65C816S-powered POC unit I decided to assemble only one byte for BRK. Since then, I have been considering making it possible to assemble something like:

or

where <SIG> would be an optional signature byte. However, the means by which I relate mnemonics and addressing modes to opcodes would make BRK <SIG> problematic, as the same opcode applies to either instruction. Hence in all likelihood, I will manufacture a fake instruction called INT, which would be entered into the assembler as:

which would be similar to the x86 instruction INT. The assembly of something like:

would be:

which would, of course, disassemble as:

My recommendation would be to treat BRK as a one byte instruction, giving you the flexibility to add a signature byte if wanted.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thank you - that was a much better answer than my sketchy question deserved

I have considered allowing both

BRK #whatever
and just
BRK

- since I'm using flex/bison to implement the assembler, this should be a doddle. Having an optional, configureable padding byte seems like a useful extension (and also something that has very little implementation cost).

That's right; the CPU reads and ignores the immediate operand "signature", skipping over it. The BRK handler may subsequently look back and read the operand, but that's something for software to implement -- or not.


Adding a signature byte is certainly worthwhile. But making it optional could be dangerous. There's no problem if the BRK terminates your program, never to return -- and perhaps some assemblers neglect the signature on the assumption that BRK means termination. But if you do expect to resume execution it's imperative that the code following the BRK appear in the right place. You will encounter "unexpected results" if the next opcode appears in the spot where the signature belongs!

It seems to me the safest thing would be for your assembler to insert a default signature if the user fails to supply one. (Or at least issue a warning.)

-- Jeff

My assembler accepts BRK as either an implied instruction (no operands) or an immediate instruction with an 8-bit literal operand.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Like many others here, the assembler I wrote supports both implied (no signature byte) and immediate (signature byte) address modes.

I also added zero page mode to make it look more like the COP instruction of the 65816 (at least, what my reading of the WDC standard says COP should look like. I'd've written it differently, but I wasn't there). Turnabout is fair play; my assembler also accepts immediate address mode for COP as an extension.

The main difference between the two then is that I allow BRK an implied mode that COP doesn't get.

I've got to say that I never thought about adding a warning to a "no operand" BRK instruction.

I think the safest and friendliest thing is if the assembler requires you be explicit, something like this, maybe:

Cheers,

-- Jeff
[Edit: remove complicated & superfluous paragraph ]

Just my opinion, but I think you guys are making it too complicated. If it were me, I'd assemble BRK as an instruction with no operand and create the fake instruction INT <SIG> for cases where a signature byte is to follow the BRK opcode—this can be easily implemented as a macro.

Alternatively, since WDC describes BRK as "...a 2 byte instruction. The NMOS and CMOS devices simply skips the second byte (i.e. doesn’t care about the second byte) by incrementing the program counter twice.", make your assembler treat it as a two-byte instruction and require the signature byte. Having it both ways, I think, opens the door to programming anomalies.

My reasoning behind this is 65xx instructions with multiple addressing modes for the same mnemonic have unique opcodes, for example, ROL <ADDR> and ROL A (rotate accumulator). BRK and BRK <SIG> would have the same opcode, requiring special case testing in the assembler to determine what the programmer is trying to accomplish.

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?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I agree, actually. But my explanation was poor; I did make it sound overly complicated!

Yes. Having it both ways is asking for trouble. I support treating it as a two-byte instruction and requiring the signature byte, as you say. Since it's required, that means there'll be a warning if it's absent (ie, a warning if the BRK mnemonic in the source code isn't accompanied by an operand to specify the signature byte).

-- Jeff
[ Edited to add clarification to last sentence]

I'm not at all sure I understand your point. 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).

The fact that the BRK opcode itself is always $00 is of no importance. One of the reasons for an assembler in the first place is that the numeric values of the opcodes are hidden precisely because the programmer shouldn't have to remember what they are.

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?

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.

So I would be reluctant to require a signature byte. 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:



An alternative would be to allow a macro named BRK to override the instruction named BRK, but in my design it's very easy to add address modes to instructions and rather harder to override instruction names with macros. There are several reasons for allowing it, though, so I'm thinking about ways to do so.

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.


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.


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.


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.


So would I, as mentioned a few posts ago. Continue to treat the BRK mnemonic as an instruction that takes no operand.


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.


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).

I lean towards treating BRK as an implied instruction that triggers an interrupt that was meant to be used for debugging and, therefore, most likely not intended to be returned from.

Actually, BRK is a stack instruction according to the WDC literature. Also, although BRK is very often used for debugging, especially inside a machine language monitor, that was not its original purpose.

Prior to the ready availability of EPROMs (and, later, EEPROMs), BRK was used to assist in patching PROMs. Since the BRK opcode is $00, "blowing" all the fuses at a particular address and selectively blowing the fuses at the next address would set up BRK followed by a signature byte. In the PROM, the IRQ/BRK vector pointed to some front end code that, if the interrupt was a BRK, would route the MPU to a patch area in the PROM. To allow more than one patch to be in the ROM, the signature byte would be gotten by sniffing the stack to get the value of the PC that was pushed when BRK was executed. The signature byte would tell the patch handler which patch to execute. Code could be burned into that patch area that ultimately returned control either to the address two bytes beyond the BRK instruction (with an RTI), or elsewhere in the ROM by tinkering with the PC value on the stack.

So BRK was not an instruction "...not intended to be returned from." An instruction from which no return is possible is STP, found in the WDC 65C... family.

Aside from the above, BRK can be used to call operating system services from a foreground program without that program having to know entry addresses. The signature byte following BRK can be used as an index into operating system services (up to 255 of them, if desired—one signature would be reserved for an actual BRK). This usage of BRK is particularly handy with the W65C816S, due to its convenient stack addressing instructions.


That zero byte is more useful than one might think at first blush! Although not directly applicable, reading up on the x86 INT instruction would give you some idea as to what can be done with a software interrupt.

[Edit: fixed an omission in the code. —BDD]

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!