| |
 | Posted by Iain Buclaw
in reply to Timo Sintonen |  Permalink Reply |
|
Iain Buclaw 
Posted in reply to Timo Sintonen
| On 8 Mar 2016 7:55 am, "Timo Sintonen via D.gnu" <d.gnu@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.
|
