[M3devel] m3_load/store using bitfields for everything

[Tony Hosking]

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/20090601/8f2baa59/attachment-0001.html>