[M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)

[Jay K]

I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.


I have some extra time today, so, plan:
  retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
  test undo just the bitfield insert/extract change, see if that is the problem 
  work through the others if not 
  Possibly verify mod/div test coverage (unless it is the problem, in which
  case if I put it back, no need for test coverage, probably nobody will ever
  touch it again, which is fine. :) )
 I'm pretty sure I tested the set stuff well because I was very nervous but
  if others are ruled out I'll undo or test it.
  (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
 set changes. Only through experimentation/testing could I know that
 the definition of bit indices matched up between hand.c and the btc/bts instructions,
 it appeared to be a very convenient coincidence.)


I am surprised that I386_* working and broken.
I would think wordsize and endian is all that matters here.


I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
But moving up to 4.4.x or 4.5.x is welcome too. :)


 - Jay
 

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 17:58:29 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>  I might have depended on Irix o32 to get up to a working gcc, but no matter.
>  I agree if they drop it, we have to.
>  Though we could also keep multiple gcc versions if there was really something we wanted,
>   but that's not likely.
>  A C generating backend also solves this.
>
>
> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
> But I won't guarantee that now and am very willing to undo them if there is a problem.
>  (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>
>
>  I don't remember about div/mod.
>  While it seems "obvious" that the change is correct, it could be that that part of
>  gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>
>
> I'm also not optimizing at all.
>
>
> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
> easily, and I'm also not keen on the huge testing matrix.
> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>
>
> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>
>
> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>  SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>
>
>  - Jay
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 09:59:02 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>
>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>
>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>
>> On 14 May 2010, at 06:27, Jay K wrote:
>>
>>>
>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>> - my changes to set operations
>>> - my change to div/mod
>>> - Tony's to bit field operations
>>>
>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>
>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>> to keep them if they don't work.
>>> (Well, hopefully the NT386 versions can stay. :) )
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>> I'll figure it out. Hopefully soon.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>
>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>
>>>>>
>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>
>>>>>
>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>> (gdb) disassem
>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>> 0x00000000004bd02c : nop
>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>
>>>>>
>>>>> This seems like it'll be tough going. :(
>>>>>
>>>>>
>>>>> I think I'll try with PIC turned off.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>
>>>
>>
>