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

Sat May 15 07:58:57 CEST 2010

> COMPONENT_REF is difficult because of the lack of type info I think
That's what I thought.
It's unfortunate imho.
We could probably do better fairly easily. ?
  Heck, with the possible major upside of having gdb work? (I don't mean m3gdb).
I'm still bothered by the problem I had on OpenBSD/mips64 where a "bitfield ref" with a high byte offset
was treated incorrectly by the compiler, where a component ref would surely have worked.

 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:14:54 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>
>
> On 14 May 2010, at 23:10, Jay K wrote:
>
>>
>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>
>> BIT_FIELD_REF considered harmful
>>
>> We should try to use COMPONENT_REF instead.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>> A more accurate one, which shows a problem, is:
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> But I'm still having trouble convincing myself.
>>> I guess the second might give you the 10th bit.
>>> Er, the 9th.
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>>
>>> a = 1 << 9;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> 1 0
>>> 0 1
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>
>>>> Er.
>>>> first: a = (a>> 22) & 1;
>>>> second: a = (a << 22)>> 31;
>>>>
>>>> are actually darn close, maybe the same.
>>>> Let's just be lame and test in C:
>>>>
>>>> #include
>>>> int main()
>>>> {
>>>> unsigned a = ~0;
>>>> unsigned b = (a>> 22) & 1;
>>>> unsigned c = (a << 22)>> 31;
>>>> printf("%x %x\n", b, c);
>>>> return 0;
>>>> }
>>>>
>>>> both print 1. So I remain a bit uncertain.
>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>> I might dig more before commiting the undo.
>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Tony I think it is your change to extract_mn.
>>>>> Try it with SOLsun for example.
>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>
>>>>>
>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>> 77,78c77,78
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 118,119c118,119
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 197,198c197,198
>>>>> < srl %g1, 21, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 21, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 236,237c236,237
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 273,274c273,274
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>>
>>>>>
>>>>> This is not optimized.
>>>>> They seem equally optimal, but very different.
>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>> srl+and is clearer.
>>>>> I don't remember which of these worked.
>>>>>
>>>>>
>>>>> < srl %g1, 22, %g1
>>>>>
>>>>> < and %g1, 1, %g1
>>>>>
>>>>> ---
>>>>>
>>>>>> sll %g1, 22, %g1
>>>>>
>>>>>> srl %g1, 31, %g1
>>>>>
>>>>>
>>>>>
>>>>> I read the first as:
>>>>> extract bit 22, plus or minus 1
>>>>> vs.
>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>
>>>>>
>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>