[M3commit] CVS Update: cm3

[Tony Hosking]

Yes, Alpha was little-endian (that was the way of Digital).  Big-endian was a west coast phenomenon.  ;-)

On 14 Dec 2009, at 11:22, Jay K wrote:

> I assumed Alpha was little endian because it ran NT.
> Then again, I know, a lot of chips go either way these days (PowerPC little endian for NT and presumably XBox360, big endian for Mac and I think Linux and AIX?)
> 
> Target.m3:
> 
>     (* big endian *)
> 
>     IF TextUtils.StartsWith(system, "PA")
> 
>             (* MIPS is definitely ambiguous! *)
>             OR TextUtils.StartsWith(system, "MIPS")
>    
>             (* PPC is a little ambiguous? *)
>             OR TextUtils.StartsWith(system, "PPC")
> 
>             OR TextUtils.StartsWith(system, "SPARC")
>             OR TextUtils.StartsWith(system, "SOL") THEN
>         Little_endian := FALSE;
>     END;
> 
> Anyway it shouldn't be hard to track down.
> I'll probably divert to SPARC64_SOLARIS first, or maybe PPC64_{LINUX,DARWIN} (iMac G5 arrived recently, though PPC64_AIX hardware has been sitting around...)
> 
> The code I put in parse.c is definitely wierd, but I really thought it was correct, and it /has/ no survived a fair number of combinations. I do cross builds /almost/ without considering host and target. Er, except you can't cross from 64bit to 32bit..I'll probably fix that pretty soon as it has started hitting me more often... it's just something where the compiler gets confused and does host math with target limitations, where it should do target math.
> 
>  - Jay
> 
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Dec 2009 10:46:25 -0500
> To: jay.krell at cornell.edu
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> On 14 Dec 2009, at 10:43, Jay K wrote:
> 
> I know I know. I know exactly the code. I rewrote it, at least once.
> Cross compiling works.
> Native does not.
> It must be the threshold variables in RTCollector.
> 
> Yeah, I've been bitten by just that scenario in the past -- those are the earliest use of FP in the run-time linker.  If they are broken you find out quickly.  Can you take a look at the gcc m3cg code for FP?  It worked at one point just fine on native Alpha 64-bit, so should not be too hard to fix.
> 
> I really thought I understood that code.
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Dec 2009 10:38:06 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> This suggests an m3cg backend compiler problem for floating point on SPARC64.
> 
> On 14 Dec 2009, at 14:40, Jay Krell wrote:
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	09/12/14 14:40:15
> 
> Modified files:
> 	cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTMachine.i3 
> 	cm3/m3-libs/m3core/src/unix/: m3makefile 
> Removed files:
> 	cm3/m3-libs/m3core/src/runtime/SPARC64_SOLARIS/: RTSignal.m3 
> 
> Log message:
> 	updates so SPARC64_SOLARIS bootstrap can build
> 	(possible tangent related to getting SPARC64_OPENBSD
> 	to work -- problem apparently with the floating point
> 	constants in RTCollector, such that Behind() is
> 	always TRUE, even for the first allocation, so
> 	access violate trying to garbage collect too
> 	early, when self is still NULL)
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20091214/6d6e6d82/attachment-0002.html>