Object file questions

[Timo Sintonen via D.gnu]

On Sunday, 17 August 2014 at 11:35:33 UTC, Artur Skawina via 
D.gnu wrote:

> It works for me:
>
>    import volat; // module w/ the last Volatile(T) 
> implementation.
>
>    struct uartreg {
>        Volatile!int sr;
>        Volatile!int dr;
>        Volatile!int brr;
>        Volatile!int cr1;
>        Volatile!int cr2;
>        Volatile!int cr3;
>        Volatile!int gtpr;
>
>        // send a byte to the uart
>        void send(int t) {
>          while ((sr&0x80)==0)
>          {  }
>          dr=t;
>        }
>    }
>
>    enum uart = cast(uartreg*)0xDEADBEAF;
>
>    void main() {
>       uart.send(42);
>    }
>
> =>
>
> 0000000000403620 <_Dmain>:
>   403620:       b8 af be ad de          mov    $0xdeadbeaf,%eax
>   403625:       0f 1f 00                nopl   (%rax)
>   403628:       b9 af be ad de          mov    $0xdeadbeaf,%ecx
>   40362d:       8b 11                   mov    (%rcx),%edx
>   40362f:       81 e2 80 00 00 00       and    $0x80,%edx
>   403635:       74 f1                   je     403628 
> <_Dmain+0x8>
>   403637:       bf b3 be ad de          mov    $0xdeadbeb3,%edi
>   40363c:       31 c0                   xor    %eax,%eax
>   40363e:       c7 07 2a 00 00 00       movl   $0x2a,(%rdi)
>   403644:       c3                      retq
>
> Except for some obviously missed optimizations (dead eax load,
> unnecessary ecx reload), the code seems fine. What platform
> are you using and what does the emitted code look like?
>
>> Also if I have:
>> cr1=cr2=0;
>> I get: expression this.cr2.opAssign(0) is void and has no value
>
> That's because the opAssign returns void, which prevents this
> kind of chaining. This was a deliberate choice, as I /wanted/ to
> disallow that; it's already a bad idea for normal assignments;
> for volatile ones, which can require a specific order, it's an
> even worse one.
> But it's trivial to "fix", just change
>
>    void opAssign(A)(A a) { volatile_store(raw, a); }
>
> to
>
>    T opAssign(A)(A a) { volatile_store(raw, a); return a; }
>
> artur

I am compiling for arm and I am sorry I misinterpreted the 
optimized code. Actually the code is correct but it still does 
not work.
The problem is that the call to get the tls pointer for 
volatile_dummy seems to corrupt the register (r3) where the this 
pointer is. The call is inside the while loop.  After removing 
tha call by hand in the assembly everything works. R3 is usually 
pushed into stack when it is used in a function. I have to check 
what is wrong in this case.