mul(a.q,b.q), add(a.q,b.q), sub(a.q,b.q), shl(a.q,b.q)

[GPI]

, shr(a.q.b.q) and IsOverflow().

c=Mul(a,b) -> c=a*b
c=add(a,b) -> c=a+b
c=sub(a,b) -> c=a-b
c=shl(a,b) -> c=a << b
c=shr(a,b) -> c=a >> b

When a Overflow is happend after one of this functions, IsOverflow() should return #true, otherwise #false. The result of MUL() should be identical to a*b, even when a overflow is happend.
btw: shr is neccassary, because shr(%10000000, -63) is possible.
Only for Quads neccassary.

[wilbert]

c=Mul(a,b)

If c would be declared as long instead of quad, there could also be an overflow with assigning the result. Besides that, the functions you propose would need to store the overflow flag in a threaded variable after each calculation.
Maybe something like mul(a.q, b.q, *IsOverflow = 0) would be more logical where you could pass an optional pointer to an overflow variable if you want the overflow result like c=mul(a, b, @overflow_flag)
This way it would be very clear that the overflow is the result of that specific calculation.