[M3devel] overshift/overflow

[Tony Hosking]

I already answered these questions.

On 4 Mar 2010, at 01:44, Jay K wrote:

> Tony, these two questions seemed to go unanswered:
>  
> 1)
>  
> What should this code do:
>  
>  
> Word.LeftShift(..., 100); (* where 100 >= BITSIZE(INTEGER),
>  and similar for Long.LeftShift and shift >= BITSIZE(LONGINT) *)
>  
>  
> I think m3front should generate a warning

It does generate a warning.

> and then either generate the same code as today,
> or something smaller where it only generates code
> to issue the runtime error.

The code for the shift doesn't know that the warning has been generated, since it is all in the checking of the arguments.

> The warning is missing.

No, it is generated.

> "Generating the code same as today" is harder on backends,
> since they have to check for this condition and handle it somehow,
> though it doesn't matter much what they do, since the runtime
> error generation will always run and anything after it never will.

Why can't a backend simply generate code for the large shift, as if it had been a call to Word.Shift(..., 100)?

> 2) What should this code do:
>  
>  
> EVAL -FIRST(INTEGER);
>  
>  
> I believe the frontend should issue a warning.

Why?  The front-end does not reason about overflow (except when computing compile-time constants).  Overflow is a run-time concept!!!!!!!!!!!!!

> And then generate the same code as today.
> Just the warning is missing.
>  
>  
>  
> 3) Aside, and not a question.
> I believe, esp. at this point, the notion that overflow checking is a per-thread setting
> is a mistake. It has "never" been used, save on a small number of targets.
> It is too late to foist that change on any code thread-wide.
> The correct thing to do is introduce different interfaces/modules/types/functions
> which either always do overflow checking, or, perhaps but less likely,
> new interfaces/modules/types/functions that are runtime configurable, as
> INTEGER was originally speced.

NOOOOO!!!!!!!  That will impose an undue expense on targets where such checking is expensive.  Targets where trap handlers can be used to catch overflow will enable it to be turned on via FloatMode.  Targets that don't support it efficiently don't have to!

>  Even the original spec not so great in my opinion.
> There are too many things to code correctly, let alone worrying about "this"
> possibly varying underneath you. The overall system is too much a combination
> of different code to expect just because one set of code wants integer overflow
> to be an error, that all the code can deal with that.
> Better to have separate interfaces/functions/types for the different functionality.
>  
>  
>  
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100304/b6c3043e/attachment-0002.html>