mode bits - an unusual approach seen elsewhere

[BigEd]

Nearby, we were discussing mode bits, in the context of enhanced or extended 6502 architectures:

Dr Jefyll wrote:

Proxy wrote:

...the E Flag, or "Enable Carry" Flag. [...] that way you don't need to constantly set or clear the flag before Adding/Subtracting something.

This makes me uneasy, because you're adding another Mode Bit. I'm reminded of a quotation that appears in The Soul Of A New Machine. Ed de Castro (a high-level manager/exec at Data General at the time) said something more or less as follows. "The trouble with Mode Bits is you're always getting tied up in your own underwear" (!) :lol:

BillG wrote:

Chromatix wrote:

The problem with mode flags is that you have to ensure you're in the correct mode before executing any instruction that depends on them. The 6502 only has the Decimal flag, which is relatively straightforward to handle by clearing it at Reset and on interrupt entry, and only setting it briefly on the comparatively rare occasions it's needed.

A notorious mode flag is the direction bit on x86 processors to determine whether the "string" instructions automagically increment or decrement the index register(s). The usual convention is to leave it clear except for setting it temporarily when decrementing is needed. Things can get weird if something left it set.

I've been following along as Hoglet and Revaldinho pursue a project related to the F100, a nearly-unknown British microprocessor from the 70s. It turns out that the machine has an unusual approach to mode bits and the status bits, which might be worth considering for future 6502 extensions...

The subroutine call instruction, CAL, pushes the processor status word onto the stack, and there are two instructions to return from a subroutine: RTN and RTC. RTN restores the status, whereas RTC discards the stacked value, so the caller can for example see the carry bit as produced by the subroutine.

But more interesting, and perhaps the reason for this arrangement, is that the mode bit M, which is used to enable carry-in to addition and subtraction, is cleared by CAL. Therefore any setting of M is scoped to the current subroutine level, which might help with reducing the kinds of bugs which can arise if a subroutine is called with different mode from what it expects, and also with reducing the amount of setting and clearing that's done.

It's true that the 6502 doesn't push P with a JSR. But it does push it with a BRK, so a similar kind of argument could apply if BRK was used as a software interrupt, or if there was some other way of using a different calling convention. Perhaps a mode bit...