[M3devel] m3_load/store using bitfields for everything

[Jay]

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/20090531/3e2ebb13/attachment-0002.html>