[M3devel] m3_load/store using bitfields for everything

[Jay]

Yes I will test some variations, esp. targets not historically affected by the bitfield behavior but that haven't passed -O3 yet, since they are easier for a few reasons and more numerous (PPC_DARWIN, PPC_LINUX, AMD64_FREEBSD, etc.)
 
 
ARM_DARWIN is a little wierd due to the 4.2 base, MIPS64_OPENBSD I haven't booted the machine in months and it is very slow (my /plan/ is to get all of MIPS{32,64}_{OPENBSD,NETBSD,IRIX,LINUX}, but it's slow going, I had difficulty installing some of them, only got Irix and OpenBSD running, and some of those combinations are invalid e.g. MIPS32_OPENBSD -- OpenBSD never 
has "biarch" systems, only ever pure 32bit or pure 64bit).
 
 
Moving ARM_DARWIN forward to 4.3 isn't impossible but I think easier to track and wait for Apple here than anything else.
 
 
I ran an AMD64_LINUX test on birch but didn't wait for it.
 
 
SPARC32_LINUX also has a wierd problem that I can retest.
When I compile with -fPIC I get I think crashes during initialization.
I haven't figured out the problem.
Without -fPIC works ok, even for shared libraries, surprising.
 
 
 - Jay


----------------------------------------
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: m3_load/store using bitfields for everything
> Date: Fri, 22 May 2009 09:45:08 +1000
>
> Jay, can you try these again with the latest fix I put in place?
>
> On 20 May 2009, at 09:14, Jay wrote:
>
>>
>> m3_load/store using bitfields for everything caused module-global
>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked
>> around that by declaring that the module-globals are at least of
>> size 2 * biggest_alignment.
>>
>> It caused module-global references to disappear on ARM_DARWIN as well.
>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't
>> occur and PutChar eventually failed an array bounds check.
>>
>> Is this just too fragile and the failsafe form should always be used?
>>
>> Or, it fails spectacularly consistently enough that it must also be
>> working consistently enough and leave it?
>>
>> Would "component ref" (ie: struct) and declaring more type
>> information about module segments be a good compromise maybe?
>> Probably.
>>
>> - Jay
>