Re: Decrement And Branch

On Wed, 14 Aug 2024 9:10:01 +0000, Anton Ertl wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Like I said, I wondered why this sort of thing wasn't more common ...

>
For the early RISCs, the pipeline was designed for early branch
execution.  Performing an ALU op before the branch did not fit that
kind of pipeline.

MIPS would disagree.

However, having a branch-and-subtract would have been possible.  But
how would that have interacted with the branch delay slots that many
of them had?  I guess one could perform the subtract before the
instruction in the delay slot, and take the branch afterwards (if it
is taken).

MIPS pipeline performed Branch Target Calculation by pasting bits
from the instruction onto bits vacated from IP.
Most of the rest of us performed BTC in the Decode stage of the
pipeline.

So it would actually fit.  Why was it not done?  Maybe the idea was
that induction-variable elimination would usually eliminate the
subtract anyway, so why complicate the architecture with such an
instruction?
>
For over a decade, Intel decoders have decoded many sequences of ALU
and branch instructions into one uop, so they can do at a
microarchitectural level what you are asking about at the architecture
level.  Other microarchitectures have followed this pattern, and
RISC-V seems to make a philosophy out of this.

On the Intel side they mostly depend on prediction.
On the RISC-V side they mostly depend on fusion. As far as I understand,
They only fuse pairs not ADD-CMP-BCs.

ARM A64 OTOH seems to put everything into an instruction that fits in
32 bits, and while they have instructions (TBNZ and TBZ) that tests a
specific bit in a register and branch if the bit is set or clear, they
have not added a subtract-and-branch or branch-and-subtract
instruction.  Apparently the uses for such an instruction are not that
frequent.

My 66000 finds use cases all the time, and I also have Branch on bit
instructions and have my CMP instructions build bit-vectors of outcomes.
I subscribe to the notion that what one can fit into an instruction
should fit in an instruction--where I differ is access to constants
as operands {immediates and displacements} of all convenient sizes;
with the disclaimer that not everything should be an instruction.

- anton