[M3devel] m3_load/store using bitfields for everything

[Tony Hosking]

I think my old PPC_DARWIN installs are pre-LONGINT.  Is there a  
LONGINT-capable bootstrap archive for PPC_DARWIN lying around anywhere?

On 22 May 2009, at 11:18, Tony Hosking wrote:

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