[M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?

[Tony Hosking]

Whenever you cross build you should do a subsequent native bootstrap to eliminate those.

On 30 Sep 2010, at 07:14, Jay K wrote:

> 
> So..we can't fully cross build a 64bit target from a 32bit host because some code
> wants to declare arrays that fill memory, like so that indexing them never fails
> an overflow check:
> 
> 
> TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example 
> 
> 
> I'm faced with a few choices:
>  - do nothing 
>  - have the front end pin the sizes to its maximum
>     Leading to such code to fail if it actually operates on data larger than 2GB
>  - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less
>  - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long",
>      (roughly: "long" suffices instead on most 64bit systems)
>   - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c
> 
> 
> Extremely similarly btw:
> 
> 
> TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example 
> TYPE T2 = RECORD a,b,c:T1; END;
> 
> 
> which is just to say, it isn't just about total array sizes, but also field offsets.
> 
> 
> (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...)
> 
> 
> 
> I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code.
> e.g. m3front/src/types/Type.i3/Info, and then all its users.
> 
> Should these types use a different and unsafe form?
> Do we have a convenient unsafe form?
> 
>  - Jay
>