www.digitalmars.com         C & C++   DMDScript  

D.gnu - How to say there is a struct of this type at this memory location?

reply Taylor Hillegeist <taylorh140 gmail.com> writes:
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!
Mar 07 2016
next sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Monday, 7 March 2016 at 21:12:02 UTC, Taylor Hillegeist wrote:
 switched from LDC because i couldn't get the section attribute 
 working on 0.14.
LDC 0.14 is ancient at this point. What you are looking for is ldc.attributes.section("..."), which is available from LDC 0.17.0: https://wiki.dlang.org/LDC-specific_language_changes#.40.28ldc.attributes.section.28.22section_name.22.29.29 — David
Mar 07 2016
parent Taylor Hillegeist <taylorh140 gmail.com> writes:
On Monday, 7 March 2016 at 23:58:11 UTC, David Nadlinger wrote:
 On Monday, 7 March 2016 at 21:12:02 UTC, Taylor Hillegeist 
 wrote:
 switched from LDC because i couldn't get the section attribute 
 working on 0.14.
LDC 0.14 is ancient at this point. What you are looking for is ldc.attributes.section("..."), which is available from LDC 0.17.0: https://wiki.dlang.org/LDC-specific_language_changes#.40.28ldc.attributes.section.28.22section_name.22.29.29 — David
I agree its an outdated version but still seems to be the most recent version in the repo for ubuntu 15.10. It was easier to use the prebuilt binaries for gdc.LDC binarys need to be built from source for arm support. At least it did seem that way. not that I prefer one over the other. thanks for the reply.
Mar 07 2016
prev sibling parent reply Timo Sintonen <t.sintonen luukku.com> writes:
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.
Mar 07 2016
parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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.
Mar 08 2016