Hi Travis, - Do we have a type like #Addr whose loads/stores have volatile semantics?
Nope - Do we have any primops with volatile semantics at all? We have atomicReadIntArray#, atomicWriteIntArray# prim ops, the read/write on MutableByteArray# will introduce proper memory barriers. However there's no Addr# equivalent yet. - Are there any tricks one could use to get volatile semantics out of base’s peek/poke functions? It's always possible to write cbits for volatile load/store. To avoid the overhead of unsafe foreign ccalls, the proper thing to do would be to add primops, and lower them to MO_AtomicRead/MO_AtomicWrite at the Cmm level. Cheers, Cheng On Fri, Sep 9, 2022 at 7:14 PM Travis Whitaker <pi.boy.tra...@gmail.com> wrote: > > Hello Haskell Friends, > > Recently I noticed some strange behavior in a program that uses peek/poke to > manipulate memory mapped hardware registers, that smells a lot like missing > volatile semantics to me. It hadn’t occurred to me that peek/poke might not > have volatile semantics (they return an IO, and that IO has to happen, > right?), but naturally once they’re lowered all such bets are off. This made > me wonder: > > - Do we have a type like #Addr whose loads/stores have volatile semantics? > > - Do we have any primops with volatile semantics at all? > > - Are there any tricks one could use to get volatile semantics out of base’s > peek/poke functions? > > Poking around, I’m afraid the answer to all three of these is “no.” If so, > I’d be very interested in contributing volatile load/store primops and > working out some way to make them easily available from Foreign.Storable. > Does no such thing currently exist or am I missing something? > > Thanks for all your ongoing efforts, > > Travis > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
