[M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
Rodney M. Bates
rodney_bates at lcwb.coop
Sun May 16 03:59:18 CEST 2010
Jay K wrote:
> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
> And that bit offsets are interpreted differently for big endian and little endian.
> I can NOT confirm that I386_LINUX was broken.
> As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
>
>
> I happen to then try a bunch of big endian platforms.
>
>
> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
> across all architectures, at least for a given wordsize/endian.)
>
>
> I should admit something.
> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
> Lately for this reason I've been removing them from code where I can.
> Clearly they have a place, where compactness of data is of the prime importance.
>
>
> It's possible this is just me, that more expert programmers can readily imagine just how
> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
> therefore they can determine the layout from glancing at the declaration.
>
According to my C '99 standard, just about everything about bit field layout is
implementation-defined, except for the bit count of each field. Harbison and
Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
using bit-twiddling operators instead of bit fields. Failing that, they recommend
doing experiments with your particular compiler to verify your assumptions. Obviously
not possible for portable code.
They do suggest that the fields will likely be laid out right-to-left on a little-endian
machine and conversely. But even there, it matters what size of "unit" is laid out
this way (a native word, for example) before moving on to the next unit, and that
is also implementation-defined.
>
> I just can't imagine what would be obvious.
> Simple example:
>
> typedef union {
> unsigned AsInt32;
> struct { unsigned a : 1 } Bits;
> } T1;
>
>
> T1 t;
> t.Bits.a = 1;
>
>
> printf("%x\n", t.AsInt32);
>
>
> prints 1 or 0x80000000 or what?
>
>
> It could be there are obvious rules, and they are endian dependent, but that otherwise
> all ABIs and compilers define them the same.
> If that is the case, I think we could get something more "optimal".
> However, notice how similar the "optimized" code was.
> And we could easily generate that without a bitfield ref.
> Just shift right and and with a constant, instead of shift left and then right.
>
>
> Could be that the decision is target-dependent as to what is optimal though.
>
>
> - 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>
More information about the M3devel
mailing list