<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
ARM_LINUX looks ok.<BR>
<BR>
Now..I experimented with the size/alignment of the module-globals.<BR>
If I decrease them to 8, it infects the uses of "components" of it (bitfields).<BR>
<BR>
<BR>
RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v<BR>retrieving revision 1.102<BR>diff -u -r1.102 parse.c<BR>@@ -2989,7 +2989,7 @@<BR> gcc doesn't think it fits in a register, so that loads out of it do get<BR> their offsets applied. */<BR> TREE_TYPE (v)<BR>- = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);<BR>+ = m3_build_type (T_struct, 8, 8);<BR> layout_decl (v, BIGGEST_ALIGNMENT);<BR> TYPE_UNSIGNED (TREE_TYPE (v)) = 1;<BR> TREE_STATIC (v) = 1;<BR>
<BR>
bl RTOS__Write(PLT)<BR> .stabn 68,0,79,.LM45-.LFBB8<BR>.LM45:<BR> ldr r3, .L40+4<BR> ldr r1, [fp, #-16]<BR> ldr r2, [r1, r3]<BR> ldrb r1, [r2, #52]<BR> mov r3, #0<BR> mov r1, r3<BR> strb r1, [r2, #52]<BR>
<BR>
<BR>
Those "b for byte" shouldn't be there.<BR>
<BR>
The problem is more obvious on the reads -- lots of shifting and masking.<BR>
<BR>
.stabn 68,0,78,.LM44-.LFBB8<BR>.LM44:<BR> ldr r3, .L40+4<BR> ldr r1, [fp, #-16]<BR> ldr r2, [r1, r3]<BR> ldrb r3, [r2, #52]<BR> and r1, r3, #255<BR> ldrb r3, [r2, #53]<BR> and r3, r3, #255<BR> mov r3, r3, asl #8<BR> orr r1, r3, r1<BR> ldrb r3, [r2, #54]<BR> and r3, r3, #255<BR> mov r3, r3, asl #16<BR> orr r1, r3, r1<BR> mov r3, r3, asl #16<BR> orr r1, r3, r1<BR> ldrb r3, [r2, #55]<BR> and r3, r3, #255<BR> mov r3, r3, asl #24<BR> orr r3, r3, r1<BR> cmp r3, #0<BR> ble .L39<BR>
<BR>
<BR>
Now, I grant that this "experiment" is a bit of garbage in, garbage out, but I think showing that the size/alignment of a symbol that we use merely for generating offsets from has big affects is a little worrisome. Ok, I grant, if this is just ensuring aligned reads, that's reasonable. I should twiddle just the size and not the alignment.<BR>
<BR>
"To be constructive" if I managed to form a patch that declared the module-globals to a be struct (record) with well described/typed/sized/aligned "components" (fields/members/etc.) and we used..hm..it seems we never access fields, just offsets?<BR>
sentence was going to end "..that'd be a reasonable change?"<BR>
<BR>
Eh, for now probably not worth it, it does work given the large size/alignment and slow path for iphone, other stuff to do...<BR>
<BR>
- Jay<BR><BR><BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] m3_load/store using bitfields for everything<BR>Date: Mon, 1 Jun 2009 16:46:38 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
It isn't related to optimization. I don't think it is 4.2/4.3 specific. I'll try to show an example later (MIPS64_OPENBSD and, never looked at them, but maybe othar arm/mips will show it).<BR> <BR> - Jay<BR><BR> <BR>
<HR id=EC_stopSpelling>
From: hosking@cs.purdue.edu<BR>To: jay.krell@cornell.edu<BR>Date: Mon, 1 Jun 2009 09:01:55 +1000<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] m3_load/store using bitfields for everything<BR><BR>Jay, things changed from gcc 3.2 to 3.3. 3.3 works fine for me on all the h/w targets I've tried using -O3 (PPC, x86, AMD64, SPARC). I suspect this is specific to your gcc-apple hybrid.
<DIV>
<DIV><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span>
<DIV style="WORD-WRAP: break-word"><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span>
<DIV style="WORD-WRAP: break-word"><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span>
<DIV><BR></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></DIV></SPAN></DIV>
<DIV>
<DIV>On 1 Jun 2009, at 00:49, Jay wrote:</DIV><BR class=EC_EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=EC_EC_Apple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=EC_EC_hmmessage>The bitfield problem still seems present.<BR> <BR> <BR>m3-libs/m3core/src/runtime/common/RTIO.m3:<BR> <BR> <BR>PROCEDURE Flush () =<BR> BEGIN<BR> IF (len > 0) THEN<BR> RTOS.Write (ADR (buf[0]), len);<BR> len := 0;<BR> END;<BR> END Flush.<BR> <BR> <BR>In question is just the line "len := 0", it is line 79, len is a module-global.<BR> <BR> <BR>Without any optimization, the bitfield code yields:<BR> <BR> .stabd 68,0,79<BR> ldr r3, L53+12 @ tmp110,<BR>L51:<BR> add r3, pc, r3 @ tmp110, tmp110<BR> ; r3 contains the address of the module globals<SPAN class=EC_EC_Apple-converted-space> </SPAN><BR> mov r2, r3 @ tmp109, tmp110<BR> ; now r2 does<SPAN class=EC_EC_Apple-converted-space> </SPAN><BR> ldr r3, [r2, #52] @,<BR> ; r3 now contains the address of len<BR> str r3, [sp, #0] @,<BR> ldr r3, [sp, #0] @ tmp112,<BR> str r3, [sp, #0] @ tmp112,<BR> ldr r3, [sp, #0] @,<BR> str r3, [r2, #52] @,<BR><BR>which I believe never actually stores to the global -- at least not any value it doesn't already have.<BR> <BR> <BR>The non-bitfield code, again, not optimized, yields:<BR> <BR> .stabd 68,0,79<BR> ldr r3, L53+12 @ tmp113,<BR>L51:<BR> add r3, pc, r3 @ tmp113, tmp113<BR> add r3, r3, #52 @ D.789, tmp113,<BR> ; r3 now contains the address of len<BR> mov r2, r3 @ D.790, D.789<BR> ; now r2 does <BR> mov r3, #0 @ tmp114,<BR> ; r3=0<BR> str r3, [r2, #0] @ tmp114,* D.790<BR> ; len=0<SPAN class=EC_EC_Apple-converted-space> </SPAN><BR> <BR> <BR>Which is pretty clearly ok -- it is actually putting zero in a register and storing that in the global.<BR> <BR> <BR>Granted, this is using gcc 4.2 (the gcc-apple directory). Some/all of the volitization is skipped, but has that ever been a problem when not optimizing?<BR>(actually I think it has, I remember debugging an m3/cygwin problem early on where code got thrown out because the compiler didn't think it did anything, I don't remember the details)<BR> <BR>Anyway, the #ifndef GCC_APPLE does workaround this successfully -- cm3 does startup ok on my iphone :).<BR>It's that this bitfield stuff also caused problems on Mips so I'm leary of it, I wonder if it is just not a great idea.<BR> <BR> <BR> - Jay<BR> <BR>><BR>> >><BR>> >> m3_load/store using bitfields for everything caused module-global<BR>> >> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked<BR>> >> around that by declaring that the module-globals are at least of<BR>> >> size 2 * biggest_alignment.<BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></DIV></body>
</html>