D.gnu - How to say there is a struct of this type at this memory location?
- Taylor Hillegeist (26/26) Mar 07 2016 I'm working on getting my FRDM-kl25z board up and running with d.
- David Nadlinger (6/8) Mar 07 2016 LDC 0.14 is ancient at this point.
- Taylor Hillegeist (7/16) Mar 07 2016 I agree its an outdated version but still seems to be the most
- Timo Sintonen (14/40) Mar 07 2016 I make it this way:
- Iain Buclaw via D.gnu (53/84) Mar 08 2016 whatever works at this point.
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
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
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: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.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
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
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:whatever works at this point.I'm working on getting my FRDM-kl25z board up and running with d.(uvision)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 simulatorfrom LDC because i couldn't get the section attribute working on 0.14.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 switchedhttps://bitbucket.org/timosi/minlibd/src/61039fcbbf5845c7f18370c30857cfc034241fa2/tools/main/uart.d?at=default&fileviewer=file-view-defaultAny help would be appreciated thanks!I make it this way: shared (uartreg*) uart2=cast (shared(uartreg*))0x40004400; See for exampleThen I mark all individual registers as ahared too. The compiler may optimize register accesses when it thinks they are notnecessary. 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 structmembers 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