Overflow exception

[Stephen Weeks]

> What are the real issues with raising overflow on integer operations?  The
> exception raising mechanism is uniform, correct:
> 
> move to the global variables the arguments for the exception
> jump to *(stackBottom + excStack)
> 
> Can we dump a global function "raiseOverflow" which does the moves and
> jump and then add
> jo raiseOverflow
> after the appropriate arithmetic instructions?  Or is there something else
> subtle that I'm missing?  Will there be other issues because elsewhere the
> compiler doesn't assume that arithmetics could raise?

The real problem with overflow was we couldn't figure out a way to do it with
the C backend with any efficiency.  With the native backend, there are some
problems, but I think it's doable.  Here's my proposal for how to do it.

* Add a new primitive exception constructor (ast/prim-cons.sig).
* Split Int_mul, Int_add, Int_sub into two primitives each, one that raises and 
  one that doesn't.  The basis library will export the raising kind.
* Change various passes (like simplify-types, representation,
  remove-unused-constructors) that rely on explicit references to constructors
  so that they know about the implicit references in these new primapps.
* Change passes (like raise-to-jump) that rely on explicit raises so that they
  know about the new primapp.
* Change machine-output.sig so that each chunk now contains a special
  "overflow" label that should be jumped to by an overflowing primapp
  (Another possibility is to have a single overflow label for the program, but
   I thought that might make separate assembly harder?)

The main remaining unresolved issue is how to handle CPS raise statements in the
backend.  Right now, the backend relies on the results of handler inference so
that it can generate a direct jump to the handler if it is in the current frame.
Otherwise, it uses the mechanism you mention above.  The problem is that the
generic mechanism does not work if there is a local handler in effect since we
only setup the handler if there are nontail calls that might raise in its
dynamic scope.  

Here are the two ways I see to go

* Setup the handler if there are nontail calls or raising primapps in the scope
  of the handler.
* Figure out someway to get the direct jump information to the raising primapps
  so that they can generate the direct jump of the generic convention as
  appropriate.

Maybe the right thing to do is to give a label to each occurrence of a raising
primapp which it jumps to if there is an overflow.  Then the C and X86 backends
are really simple and the raising info is all in backend.fun.

What do you think?