[M3devel] m3_load/store using bitfields for everything

[Jay]

ARM_LINUX looks ok.

 

Now..I experimented with the size/alignment of the module-globals.

If I decrease them to 8, it infects the uses of "components" of it (bitfields).

 

 

RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v
retrieving revision 1.102
diff -u -r1.102 parse.c
@@ -2989,7 +2989,7 @@
      gcc doesn't think it fits in a register, so that loads out of it do get
      their offsets applied. */
   TREE_TYPE (v)
-    = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);
+    = m3_build_type (T_struct, 8, 8);
   layout_decl (v, BIGGEST_ALIGNMENT);
   TYPE_UNSIGNED (TREE_TYPE (v)) = 1;
   TREE_STATIC (v) = 1;

 

        bl      RTOS__Write(PLT)
        .stabn  68,0,79,.LM45-.LFBB8
.LM45:
        ldr     r3, .L40+4
        ldr     r1, [fp, #-16]
        ldr     r2, [r1, r3]
        ldrb    r1, [r2, #52]
        mov     r3, #0
        mov     r1, r3
        strb    r1, [r2, #52]

 

 

Those "b for byte" shouldn't be there.

 

The problem is more obvious on the reads -- lots of shifting and masking.

 

        .stabn  68,0,78,.LM44-.LFBB8
.LM44:
        ldr     r3, .L40+4
        ldr     r1, [fp, #-16]
        ldr     r2, [r1, r3]
        ldrb    r3, [r2, #52]
        and     r1, r3, #255
        ldrb    r3, [r2, #53]
        and     r3, r3, #255
        mov     r3, r3, asl #8
        orr     r1, r3, r1
        ldrb    r3, [r2, #54]
        and     r3, r3, #255
        mov     r3, r3, asl #16
        orr     r1, r3, r1
        mov     r3, r3, asl #16
        orr     r1, r3, r1
        ldrb    r3, [r2, #55]
        and     r3, r3, #255
        mov     r3, r3, asl #24
        orr     r3, r3, r1
        cmp     r3, #0
        ble     .L39

 

 

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.

 

"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?

sentence was going to end "..that'd be a reasonable change?"

 

Eh, for now probably not worth it, it does work given the large size/alignment and slow path for iphone, other stuff to do...

 

 - Jay


 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] m3_load/store using bitfields for everything
Date: Mon, 1 Jun 2009 16:46:38 +0000



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).
 
 - Jay

 


From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon, 1 Jun 2009 09:01:55 +1000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] m3_load/store using bitfields for everything

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. 







On 1 Jun 2009, at 00:49, Jay wrote:

The bitfield problem still seems present.
 
 
m3-libs/m3core/src/runtime/common/RTIO.m3:
 
 
PROCEDURE Flush () =
  BEGIN
    IF (len > 0) THEN
      RTOS.Write (ADR (buf[0]), len);
      len := 0;
    END;
  END Flush.
 
 
In question is just the line "len := 0", it is line 79, len is a module-global.
 
 
Without any optimization, the bitfield code yields:
 
 .stabd 68,0,79
 ldr r3, L53+12 @ tmp110,
L51:
 add r3, pc, r3 @ tmp110, tmp110
 ; r3 contains the address of the module globals 
 mov r2, r3 @ tmp109, tmp110
 ; now r2 does 
 ldr r3, [r2, #52] @,
 ; r3 now contains the address of len
 str r3, [sp, #0] @,
 ldr r3, [sp, #0] @ tmp112,
 str r3, [sp, #0] @ tmp112,
 ldr r3, [sp, #0] @,
 str r3, [r2, #52] @,

which I believe never actually stores to the global -- at least not any value it doesn't already have.
 
 
The non-bitfield code, again, not optimized, yields:
 
 .stabd 68,0,79
 ldr r3, L53+12 @ tmp113,
L51:
 add r3, pc, r3 @ tmp113, tmp113
 add r3, r3, #52 @ D.789, tmp113,
 ; r3 now contains the address of len
 mov r2, r3 @ D.790, D.789
 ; now r2 does 
 mov r3, #0 @ tmp114,
 ; r3=0
 str r3, [r2, #0] @ tmp114,* D.790
 ; len=0 
 
 
Which is pretty clearly ok -- it is actually putting zero in a register and storing that in the global.
 
 
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?
(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)
 
Anyway, the #ifndef GCC_APPLE does workaround this successfully -- cm3 does startup ok on my iphone :).
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.
 
 
 - Jay
 
>
> >>
> >> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090602/0be5cf63/attachment-0002.html>