IntInf asserts
Stephen Weeks
MLton@sourcelight.com
Mon, 12 Nov 2001 17:15:38 -0800
> My thoughts were somthing like this: switching the type of
> the IntInf primitives basically requires some function of the form:
>
> val bytesNeeded: {prim: Prim.t, args: 'a vector} -> 'a option
...
> I think it would be better if LimitCheck statements were the only things
> that gave rise to limit checks; if bytesNeeded {prim, args} = SOME x, for
> some Assign {dst, prim, args, ...} statement, then the limit check
> insertion code needs to ensure that x bytes are available at the Assign
> statement. (I think this fits in better with the limit check insertion
> formalization.) This means that LimitCheck statement would have bytes as
> an Operand.t instead of int.
Looks good to me. This cleans up the current world and makes
integration with they new approach to IntInf easy.
> How would this work in practice? IntInf_* are easy, with the proposal to
> give them the type
> val add = _prim "IntInf_add": int * int * Int.int -> int
> Then
> fun bytesNeeded {prim, args} =
> case Prim.name prim of
> IntInf_add => Vector.sub (args, 2)
> | ...
Yep.
> Array_array is a little harder. What I would propose is a quick rewrite
> after Representations have been establised.
Sounds reasonable.
> Err... Need to run to colloquium, but there is a little more. The major
> point of this is that it might give the pass that actually chooses the
> number of bytes for a limit check a little more freedom.
Also good.
And I agree that it fits with in our forthcoming formalization, which
is on the todo after the exceptions paper, which is on the todo after
the shrinker, ...