[M3devel] m3_load/store using bitfields for everything

[Jay]

http://modula3.elegosoft.com/cm3/uploaded-archives/index.html has one
and really cross-building is not a terrible option, I've done it many times including recently (ARM_DARWIN).  
 
 cd m3-sys/m3cc 
 cm3 -DM3CC_TARGET=foo  
 cd scripts/python 
 ./boot1.py foo  
 gives you cm3-boot-foo-1.tar.gz 
 copy that to "target" machine (aka machine with C compiler/linker) 
 extract it there  
 cd cm3-boot-foo-1  
 make 
 That gives you cm3, with which you can build the rest of the system. 
 boot1.py recognizes target names on the command line (using a builtin list and formating them processor/os combinations).
 My config files probe around for a viable backend, which coincides with where -DM3CC_TARGET puts it. 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> To: hosking at cs.purdue.edu
> Date: Fri, 22 May 2009 11:41:25 +1000
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] m3_load/store using bitfields for everything
>
> Don't worry --- I found one.
>
> On 22 May 2009, at 11:38, Tony Hosking wrote:
>
>> 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
>>>>>
>