can the BRK instruction be conditionalized?

ersmith

I've had reports of weird behavior of DEBUG statements in flexprop, and digging into it the offending DEBUGs all seem to have conditional BRK statements. That is,

if_e  brk #2

doesn't work properly: it seems to always be triggered, but with an incorrect or corrupted immediate value. However,

if_ne jmp #L_tmp
      brk #2
L_tmp

does work as expected.

@cgracey is there something in the hardware, or perhaps in the debug stub, that would not like conditional BRK?

ersmith

[deleted]

evanh

That is peculiar behaviour ... but I do see it is documented in the silicon doc:

Regardless of the execution condition, the BRK instruction will trigger a debug interrupt, if enabled. The execution condition only gates the writing of the 8-bit code ...

Can't think why Chip did it that way though.

Wuerfel_21

Quoting what I said on GitHub:

Yep, BRK can't be conditional. That's because the BRK instruction itself only sets the break code. The actual soft interrupt is triggered by the presence of the BRK opcode in the pipeline (and at the point that this is checked, the previous instruction hasn't completed so checking the flags would be bogus, anyways). Chip explained this at length on Zoom once, idk if its been recorded.

evanh

@Wuerfel_21 said:
... The actual soft interrupt is triggered by the presence of the BRK opcode in the pipeline ...

Oh, I guess that improves pipeline reload times, especially in cogexec.

EDIT: Hmm, not sure it'll help speed wise given debug code is always hubexec. [scratches head]

Electrodude

@ersmith , would you want to make the assembler emit a warning when it sees a conditional on a brk instruction?

ersmith

@Electrodude said:
@ersmith , would you want to make the assembler emit a warning when it sees a conditional on a brk instruction?

Yes, that's a good idea. I've checked in that change.