Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 25, 2013 8:18 pm wrote:
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on February 25, 2013 5:24 pm wrote:
> [snip]
> > Well then you'll be surprised to hear that there are more adds/subs
> > followed by a beq/bne than all logical operations combined...
>
> How many of the adds are with negative immediates (e.g., loop counter)?
>
> [snip]
> > If going all-out on flags, what about a flag for all-ones, top 16/24-bits zero (or same-sign
> > as bit 15/23), even/odd, parity etc. Half/quarter carry? Just where do you stop?
>
> I wonder if providing (user mode) exceptions for operations that lose information like overflow and storing
> to a smaller memory area when sign/zero extension from memory will not reproduce the value. (This would be
> more problematic in terms of opcode space since stores would like to use largish immediates and two or more
> register names. Using "signed-extended" store for exceptions would have a certain symmetry with loads--"zero-extended"
> stores could be simple inserts, ignoring MSbits--, but the actual use of such would seem small.)
>
> The concept of explicitly testing for arithmetic overflow for every possible operation seems excessive.
> Generating an exception (handled in user mode) would seem to avoid excessive test instructions.


You'd need to be very careful with that. Notions of overflow vary considerably between languages, and even within languages. A mismatch with the hardware just makes a hash of things. Consider C: unsigned arithmetic is defined a modulo 2**n, you definitely don't want overflow checks trapping on any of that. OTOH, overflow check would be legal for signed arithmetic (although you'll break a ton of code if you implement such). Even with signed arithmetic, if you're doing it multi-precision (say implementing long-longs on a 32 bit processor), you certainly don't want the trapping behavior on the low word.

The problem with having a mode bit to select that behavior is that setting the mode is pretty much always slow*, as changing them requires mucking with stuff in the pipeline, and the required behavior tends to change from line-to-line of code, so you'd have to bang on that a lot. Much better to have two forms of the instruction, or an easy way to check in the comparatively rare cases where you actually want the check. An always predicted "not taken" JO on x86, for example.

FWIW, S/360 has such a mode bit (and several others), in practice they're almost never changed to enable the trap (although it's not a user mode trap).


*The mode bits are a considerable source of grumbling in IEEE FP for the same reason