[M3devel] files larger than 2gig

[Jay]

> what exactly is portable C??? 

 
It may be a little bit elusive, but I think it is certainly possible.
Think of how many packages out there that you just download, extract,
configure, and make. Think of how much or how little per-system
was put into them. Think of how much or how little configure (autoconf) does,
and how applicable it is to CM3.
 
 
> performance of the compiler
> performance of the produced code (missing
> optimizations) 
 
 
Understood the compiler would be slow.
It is slow already, but this would likely be worse.
It should be possible to still get reasonable optimization but
I don't really know.


 - Jay




----------------------------------------
> Date: Fri, 26 Jun 2009 10:08:54 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] files larger than 2gig
>
> Quoting Jay :
>
>>
>> ----------------------------------------
>>> Date: Wed, 24 Jun 2009 19:10:05 -0400
>>> From: hendrik at topoi.pooq.com
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] files larger than 2gig
>>>
>>> On Mon, Jun 22, 2009 at 12:58:45PM -0400, Tony Hosking wrote:
>>>>
>>>> Yuck. Why not decompose in the backend?
>>>
>>> However we do it, large files should "just work" on systems that can
>>> handle them.
>>>
>>> -- hendrik
>>
>>
>> It should be LONGINT.
>> I'll try to get to it.
>> It might be a slightly breaking change, depending on where the
>> INTEGER size is exposed.
>>
>>
>> That shouldn't be difficult and will address all but one platform.
>> I'll try to get back to revisiting LONGINT support on NT386.
>> Then it might be interesting, though not easy, to port that backend
>> to more platforms. :)
>> One reason to do all those wierdo ports is to set a bar for
>> what an integrated backend should strive for. :)
>> Or then again again again, a C generator. That way, there'd be a chance
>> of "no more porting work". If the IL was slightly abstracted, we could
>> just generate portable C and release just one
>> portable source-ish package for all platforms.
>> There could still be binary packages for people that don't build from source,
>> but all platforms would just be a C compiler away.
>
> It has been done that way in the first SRC compilers. m3make was just
> a wrapper generating makefiles, and the compiler produced C as an intermediate
> language. It was found to be rather suboptiomal for various reasons AFAIR:
> performance of the compiler, performance of the produced code (missing
> optimizations), missing C standardization (what exactly is portable C???), ...
>
> Of course I wouldn't object a C generating backend at all, but we should
> very carefully compare its benefits with the existing backends before
> abandoning any of them.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>