How to say there is a struct of this type at this memory location?

[Iain Buclaw via D.gnu]

On 8 Mar 2016 7:55 am, "Timo Sintonen via D.gnu" <d.gnu at puremagic.com>
wrote:
>
> On Monday, 7 March 2016 at 21:12:02 UTC, Taylor Hillegeist wrote:
>>
>> I'm working on getting my FRDM-kl25z board up and running with d.
whatever works at this point.
>>
>> The issue is when i try to specify hey this struct is over here! using:
>>
>> __gshared SIM_MemMap  * SIMY       = cast(SIM_MemMap *) 0x40047000;
>> __gshared PORT_MemMap * TMP2CH     = cast(PORT_MemMap*) 0x4004A000;
>> __gshared PORT_MemMap * TMP0CH     = cast(PORT_MemMap*) 0x4004C000;
>> __gshared TPM_MemMap  * TPM0       = cast(TPM_MemMap *) 0x40038000;
>> __gshared TPM_MemMap  * TPM2       = cast(TPM_MemMap *) 0x4003A000;
>> __gshared SCB_MemMap  * SCB        = cast(SCB_MemMap *) 0xE000E000;
>>
>> and then try an set values:
>>
>> SIMY.COPC = 0; //DISABLE WATCHDOG TIMER;
>>
>> it looks like someone moves my cheese when i run in the simulator
(uvision)
>>
>> SIMY actual address ends up being 0x1FFFF0C4;
>>
>> http://dpaste.dzfl.pl/20c95c182f6c
>>
>> the whole projects is two files a linker and the file above. i switched
from LDC because i couldn't get the section attribute working on 0.14.
>> Any help would be appreciated thanks!
>
>
> I make it this way:
> shared (uartreg*) uart2=cast (shared(uartreg*))0x40004400;
>
> See for example
>
https://bitbucket.org/timosi/minlibd/src/61039fcbbf5845c7f18370c30857cfc034241fa2/tools/main/uart.d?at=default&fileviewer=file-view-default
>
> Then I mark all individual registers as ahared too.
>
> The compiler may optimize register accesses when it thinks they are not
necessary. For example, if there are multiple writes to the same register,
the compiler may remove all but the last. Repetitive reads, like status
poll may be optimized to be done just once.
>
> Gdc treats all shared variables as volatile and marking all struct
members shared solves the problem partially. However this is unstable and
buggy feature and may be removed in future.
>

I was perhaps too harsh to use the word "bug" back in the 2014 talk.  I
apologise for that, I now wish I could take that part out.

Back when shared was first added, apart from the transient nature of it
(turtles all the way down), I'm not sure anyone was sure how it should work
on a codegen level.  Let's make some details clear:

- Volatile had been removed very recently (this is around 2010 or prior I
think).
- There was no enforcement of opAssign expressions on shared data.
- There was no volatileLoad/volatileStore intrinsics to guarantee order of
reads and writes.
- core.atomic was in it's infancy, and how it would interact with the
compiler had not yet been realised.

The one thing I recognised as being "not a good thing" at the time was that
for shared data to be cached in registers.  I honestly believed that it
would be surprising for users to discover that shared data accesses had
been reordered by some optimizer pass.  And what with volatile gone from
the frontend.  I still had codegen support, and just swapped volatile for
shared, letting shared on datatypes propagate up to declarations.  I don't
recall the exact reasoning, but I know that I was aware that shared should
try to be complimentary to the atomic module.

Fast forward to now, the language specification of what shared means has
matured.  We now have proper enforcements and mechanisms in place that
prevent shared data being cached or having accesses reordered.  The atomic
library has grown up looking a little bit like C++11 atomics, but that
actually works well in gdc's favour, as that it inherits the same broad
target support.  But most importantly, it has become clear over the years
(pick any article written since 2010 on the subject) that assigning
volatile to a type whose purpose is for atomic access does not help in
supporting any of the wanted behaviours, such as a happens-before
relationship in threads.

So for the purpose of continued support for the atomic library - as well as
let's face it, a historical error in hindsight - shared will soon depart
from volatile in the C sense in gdc (this will happen in the 2.068 merge
branch).

However for those who need hardware access, shared is still your friend!
As of 2.067, volatileLoad and volatileStore are in the core.intrinsic
module, and the compiler should guarantee that using it would achieve what
the OP wants to do (please let me know if it doesn't).

I think the only thing missing is a volatileOp template that should work in
the same manner as atomicOp, but using the volatile intrinsics rather than
atomics.  Any takers to implement this? :-)

Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20160308/662a6d12/attachment.html>