[M3devel] m3_load/store using bitfields for everything

[Tony Hosking]

PPC_DARWIN did work for me at one point.  I can check it.

On 22 May 2009, at 10:09, Jay wrote:

>
> 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
>>