[M3commit] CVS Update: cm3

[Jay K]

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/42b05320/attachment-0002.html>