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

[Tony Hosking]

What hack?
Why build the entire system in cross?  That seems overly complicated.  Better to just cross-build the compiler.

On 1 Oct 2010, at 06:17, Jay K wrote:

> 
> Huh? You mean hack, cross once, unhack?
> I want to cross build as a regular occurence. The entire system.
> I already do actually. But currently only enough to get cm3.
> The problems occur if you try to build the entire system.
>   Ok, right, I left one of the hacks in actually.
>   Like TEXTs have a 2GB size limit or such.
> 
> 
> "Regular" cross builds are normal in other environments these days.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>> From: hosking at cs.purdue.edu
>> Date: Thu, 30 Sep 2010 09:42:59 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> 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
>>> 
>> 
>