Re: a bit of history, Stealing a Great Idea from the 6600

John Levine wrote:

According to Thomas Koenig  <tkoenig@netcologne.de>:

John Levine <johnl@taugh.com> schrieb:
>

It is my impression that
trapping on fixed point overflow is not very useful, and it's easier
to do a jump on overflow in the few cases where you care, or the x86
INTO which you put after the arithmetic operaion to trap if the
overflow flag is set.

>
Sanitzers would benefit greatly from trapping math.
>
However, this could get into murky territory - to be really
general, you would also need a version for trapping math with
unsigned numbers.  Just think of doing a unsigned loop with a
lower bound that, due to some error in the code or input, has an
upper bound of 0-1...

I suppose but my experience was always that the trap was the easy
part.

If it is the easy part, why does it take ~1,000* cycles ??
(*) x86 takes craploads of cycles to cross the trap barrier and back
{including the saving and restoration of registers}
Something like My 66000 takes 10 each way including the saving and restoring of registers, and the change of MMU state.

      Figuring out what to do after the trap happens is much harder.

Depends on what the trap delivers to the "other side", and also dependent
on the range of options the handler has to consider; and sometimes on
how many instructions go through that trap !?!

I've seen designs with instructions like "trap if greater than N" so
if you want to go that route, you can check for the range the
programemr declared rather than whatever word size it was rounded up
to.