[M3devel] files larger than 2gig

[Tony Hosking]

On 22 Jun 2009, at 11:36, Jay wrote:

>
> The NT386 backend internally uses a stack of 32bit words to slightly  
> optimize codegen..it seems kind of similar to what the frontend  
> does..I wonder if it is redundant..
> Anyway..
> It doesn't appear easy to extend, but with years of hindsight at  
> this point..it might be easiest to have a mode where the front end  
> decomposes 64bit operations into multiple 32bit operations.

Yuck.  Why not decompose in the backend?

> Maybe that'd be an entire "cg layer" (it appears code generators are  
> layerable).
>
>
> I'm less keen on the LONGREAL solution but still pretty keen on  
> LONGINT.
> Not right now though, maybe in a few days..
>
>
> - Jay
>
>
> ----------------------------------------
>> Date: Mon, 22 Jun 2009 16:30:03 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] files larger than 2gig
>>
>> Quoting Jay :
>>
>>>
>>> C:\dev2\cm3.2\m3-libs\libm3\src\os\Common\File.i3
>>>
>>>
>>> TYPE
>>> Status = RECORD
>>> type: Type;
>>> modificationTime: Time.T;
>>> size: INTEGER;
>>> END;
>>>
>>>
>>> size: INTEGER causes exceptions when you use the Modula-3 gui
>>> and browse to a directory with files larger than 2 gig.
>>
>> This is a known limitation on all 32 bit platforms.
>>
>>> I suggest size be changed to LONGREAL, which generally has a 53  
>>> bit mantissa
>>> (out 64 bits total) and thus can represent integers very much larger
>>> than INTEGER.
>>
>> I wouldn't like that. Sizes are no real numbers, really ;-)
>> Either use LONGINT or rely on INTEGER being large enough (64 bit
>> on all 64 bit targets).
>>
>>> LONGINT is a tempting option but doesn't help on the current NT386  
>>> platform,
>>> and I think 53 bits will last a very long time.
>>
>> What exactly was the problem in makeing LONGINT work on NT386?
>>
>>> I'm just trying out such a change and I can see it is not source  
>>> compatible:
>>>
>>>
>>> "../src/rw/FileRd.m3", line 73: incompatible argument types: MIN
>>> "../src/rw/FileRd.m3", line 140: types are not assignable
>>> 2 errors encountered
>>> "../src/rw/FileWr.m3", line 87: incompatible argument types: MIN
>>> "../src/rw/FileWr.m3", line 103: incompatible argument types: MAX
>>> 2 errors encountered
>>>
>>>
>>> Nevertheless I think it should be done, probably even for this  
>>> release