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
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