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

[Jay K]

Tony: Do you mean to  say, that if NT386 had a working LONGINT, you'd be willing to implement Target.Int via LONGINT?

I kind of think Target.Int should remain being implemented as an array of 8 bit integers.

That preserves flexibility of targeting basically "anything from anything".

 

 

Including using a pre-LONGINT compiler, with its matching m3core/libm3, to build a current compiler.

  Though I admit when I have done the most "intensive" building of various compiler versions to find when problems began, it wasn't so smooth. I think I might have resorted to always starting old, and making smaller steps not big steps, not just from very old to current, though I should try/check again.

 

 

As well, Target.Int needs to be used more in m3front, like regarding array sizes/alignment.

I think it's a pretty simple fix.

 

 

There is still a bug targeting 64bit from 32bit because of this.

The attempts to declare "maximally sized arrays" fails.

m3core has a hack where it uses 2GB or 4GB instead of the real max.

The "jvideo" package still fails to cross compile.

 

 

 - Jay
 


Subject: Re: [M3devel] RELENG again, was: Re: the LONGINT proposal
From: hosking at cs.purdue.edu
Date: Wed, 13 Jan 2010 16:53:19 -0500
CC: wagner at elegosoft.com; m3devel at elegosoft.com
To: jay.krell at cornell.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.


 
 
 - Jay

 
> Date: Wed, 13 Jan 2010 10:43:03 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] RELENG again, was: Re: the LONGINT proposal
> 
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 
> > On 11 Jan 2010, at 23:09, Randy Coleburn wrote:
> >
> >> Also, in case anyone is interested, the current HEAD fails to 
> >> compile the following packages on Windows Vista:
> >> "m3-libs\m3core"
> >> "m3-libs\libm3"
> >> "m3-tools\m3tk"
> >> So some recent changes have caused a problem.
> >
> > Did you bootstrap a new compiler? You will need to bootstrap a 
> > compiler before you can compile the revised ORD/VAL definitions.
> 
> So if I understand this correctly, should we finally get to release
> 5.8, then this compiler won't be able to compile the current trunk
> head? That is, not unless we merge this change to the release branch?
> 
> Anything else that we should do for 5.8?
> 
> 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
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100113/c982b40d/attachment-0002.html>