I belive it is okay because the 'casted' non-volatile pointer is only used once. as in, there is never a non-volatile version of the pointer that is used in more than one place that the compiler might try to optimize out. Each use jhc will generate code that creates the pointer relative to the volatile physicalAddr so it won't be able to merge them. John On Wed, Mar 6, 2013 at 10:07 PM, Kiwamu Okabe <kiwamu@gmail.com> wrote:
Hi John.
On Thu, Mar 7, 2013 at 7:59 AM, John Meacham <john@repetae.net> wrote:
include the attached header file and add the arm-addresses.lds file to the gcc or ld command line. Then you can foreign import the pointers.
If you can verify this works then I can implement it as part of the ForeignData proposal with a volatile extension and have the compiler automatically take these steps.
http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignData
so if you do this foreign import "volatile &periphBase" periphBase :: Ptr a = 0x40000000
it will automatically create the appropriate header and lds entries.
I tried this method and running test is green. But I have some question on C code outputted with Ajhc. Is it correct to cast volatile pointer with (uint16_t *)?
--- hs_main.c static wptr_t A_STD A_MALLOC fW$__fMain_ledOff(gc_t gc,uint16_t v1167729185) { *((uint16_t *)((uintptr_t)&jhc_phys_brrPtr)) = v1167729185; return SET_RAW_TAG(CJhc_Prim_Prim_$LR); } ---------
I have same success result running with below C header.
--- stm32f3-discovery/jhc_custom/rts/jhc_rts_header.h extern void jhc_phys_brrPtr; extern void jhc_phys_bsrrPtr; // without volatile -------
Best regards, -- Kiwamu Okabe
_______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc