Accessing peripheral registers - the next version

[Timo Sintonen via D.gnu]

Some thing that I have noticed in the original struct definition

> struct Volatile(T) {
>      T raw;
>      nothrow:
>      @disable this(this);
>      A opAssign(A)(A a) { volatileStore(&raw, a); return a; }
>      T load() @property { return volatileLoad(&raw); }
>      alias load this;
>
>      void opOpAssign(string OP)(const T rhs) {
>           auto v = volatileLoad(&raw);
>           mixin("v " ~ OP ~ "= rhs;");
>           volatileStore(&raw, v);
>      }
> }

There was @disable this(this)
This prevents to use a location as argument to a function, like: 
print(timer.count). Is there any reason to have this line or not? 
What about disable this() ? I will never need to create any 
instance of this type.

OpAssign did originally return void. Then I had a piece of code 
like cr1=cr2=cr3=0 which did not work. Now I return the same type 
but I think I have seen that it should return this. What should 
it return and would it make shorter code if it does not return 
anything?

The original functions had force_inline attribute. The compiler 
said it can not inline because the body is not available. Is this 
because they are templates or is this because of the intrinsic 
call? These calls are often in time critical places and inlining 
them is very important.

When these are all templated, all modules have their own 
instances of all templates for all data and operator types. That 
is lots of extra code. There are intrinsics for only four data 
types. Should I make overloads for these 4 types instead of 
templates? These functions are so short that code duplication 
does not matter.

For the outer struct (like uartregs struct in my example) there 
is compiler generated stuff like opEquals and toHash. I will 
never need them and they take a lot of space. How can I disable 
them?