[M3devel] va/loophole/integers

[Tony Hosking]

On Oct 31, 2010, at 3:20 AM, Jay K wrote:

> When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.

Possibly.  LOOPHOLE in the language expects values with equal BITSIZE.  I used it originally because LOOPHOLE as implemented seemed to do the right thing.  Probably we should use widen/chop (as defined in M3CG_Ops.i3).

> I think this is wrong in multiple ways.
> 
> 
> For 64bit targets, nothing should be done.
> Backend can check that it is given equal types.
> This might already be done.

If they are same BITSIZE then loophole is appropriate, no?

> A range check should be done.

We have a range check in VAL:

      Expr.GetBounds (ce.args[0], minu, maxu);
      EVAL Type.GetBounds (t, mint, maxt);
      IF TInt.LT (minu, mint) THEN
        (* we need a lower bound check *)
        IF TInt.LT (maxt, maxu) THEN
          (* we also need an upper bound check *)
          ce.args[0] := CheckExpr.New (ce.args[0], mint, maxt,
                                          CG.RuntimeError.ValueOutOfRange);
          Expr.TypeCheck (ce.args[0], cs);
        ELSE
          ce.args[0] := CheckExpr.NewLower (ce.args[0], mint,
                                          CG.RuntimeError.ValueOutOfRange);
          Expr.TypeCheck (ce.args[0], cs);
        END;
      ELSIF TInt.LT (maxt, maxu) THEN
        (* we need an upper bound check *)
        ce.args[0] := CheckExpr.NewUpper (ce.args[0], maxt,
                                          CG.RuntimeError.ValueOutOfRange);
        Expr.TypeCheck (ce.args[0], cs);
      END;


> Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.

This *will* raise an exception if it doesn't fit.

> Code that wants to ignore this can..well..it takes a bit if code I guess, but still.
> Similarly for LONGCARD to CARDINAL

Should be the same.

> And then, still, I don't think loophole is appropriate.
> 
> Perhaps loophole in backend isn't meant to match up to loophole in the language?
> I guess, maybe, but this seems...not intuitive.

Perhaps we should use widen/chop?

> In particular I tried making loophole use VIEW_CONVERT and I was look at the
> affect here:
> 
> libm3/.../FilePosix.m3
> 
> PROCEDURE RegularFileSeek(
>     h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
>   : INTEGER RAISES {OSError.E} =
>   BEGIN
>     WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
>       IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
>       RETURN VAL(result, INTEGER)
>     END
>   END RegularFileSeek;
> 
> 
> 
> (1034) call_direct procedure:Unix__lseek type:int64
> (1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
> (1036) store var:noname offset:0 src_t:int64 dst_t:int64
> (1037) begin_block
> (1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
> (1039) load var:noname offset:0 src_t:int64 dst_t:int64
> (1040) store var:result offset:0 src_t:int64 dst_t:int64
> (1041) set_source_line 0x96(150)
> (1042) load_integer type:int32 0
> (1043) loophole type1:int32 type2:int64
> 
> 
> 
> and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.
> 
> 
> Probably the backend should check that loophole is using two equal sized types, and then use view convert.
> Though for now at least it has to deal with these integer conversions.
> 
> 
>  - Jay
> 
>