[jhc] [BUG] Poke should use volatile.
john at repetae.net
Thu Mar 7 09:47:07 CET 2013
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
On Wed, Mar 6, 2013 at 10:07 PM, Kiwamu Okabe <kiwamu at gmail.com> wrote:
> Hi John.
> On Thu, Mar 7, 2013 at 7:59 AM, John Meacham <john at 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.
>> 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 at haskell.org
More information about the jhc