<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='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 <BR> mov r2, r3 @ tmp109, tmp110<BR>
 ; now r2 does <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 <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></body>
</html>