[M3devel] RELENG again, was: Re: the LONGINT proposal

[Olaf Wagner]

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 13 Jan 2010, at 16:45, Jay K wrote:
>
>> Yes and no. I was thinking about this too.
>> In general this "race" never ends.
>> However:
>>   - right this is first release with LONGINT, and I think there are  
>>  incompatibilities between head and release esp. wrt "ORD"
>>    (Had we added e.g. "assignability" and release was just a   
>> compatible subset, different; I think it is actually "incompatible".)
>
> We should merge head back to release for LONGINT as it is now (more   
> consistently) implemented.
>
>>   - the "race" should actually "slow down" now that I fixed the   
>> platform list problem :)
>>      but still, the "race" isn't guaranteeably gone; there might   
>> still be new language features that m3core/libm3 use
>>      (to be clear, the "front" group needs to be more careful about  
>>  using more features;
>>      for example, it would be "useful" for me to use LONGINT in   
>> m3back, and then build a non-NT386 hosted compiler, in order to get  
>>  LONGINT support into NT386, however my preference at the moment is  
>>  to use Target.Int to "simulate" 64bit arithmetic in the compiler   
>> ("constant folding" and such, as it already does for 32bit   
>> integers); the compiler basically supports targeting 32bit INTEGER   
>> even on a host with only 8 or 16bit INTEGER, as I understand).
>
> Yes, I could have made use of LONGINT but didn't so as to retain   
> cross-compilation from short to long LONGINT platforms.
>
> I don't understand what you are saying about needing to simulate   
> 64-bit arithmetic.  We can do that already.  I don't think the   
> compiler ever targeted 32-bit INTEGER on <32-bit hosts.  I would be   
> surprised if that actually works.
>
>>  If I or anyone checks that the exception is gone now in GUI file   
>> open dialog, maybe merge those changes too.
>> They are pretty small. I haven't touched rd/wr yet (well, they were  
>>  touched *slightly*).
>
> That would be good too.

Can one of you please do the necessary merges? I had a quick look,
but there were too many commits to find the relevant things quickly.

We should try to be selective and not merge just everything though;
CVS needs two labels or dates to do those three point merges
(cvs update -j -r rev1 -r rev2; build; cvs commit).

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