Support for unaligned reads/writes

[clyring]

Today, for reading and writing basic values like Int32s to locations in memory we have:

• The Storable class from base
• The Prim class from primitive
• Primops like readInt32OffAddr# and writeInt32OffAddr#

All of these have in common that they may only work for sufficiently aligned addresses. (...though for the primops this is not currently documented anywhere obvious.) This leads library authors to writing embarrassing workarounds like this one when there is a need to read from or write to a potentially un-aligned memory location. The code this workaround produces on non-whitelisted architectures is correct but very poor.

It's clear to me that GHC should provide a family of primops like readInt32OffUnalignedAddr# and writeInt32OffUnalignedAddr#. (This should be easy to implement.)

What's less clear to me is whether and how more polite wrappers should be provided. For example, adding a pokeUnaligned :: Ptr a -> a -> IO () method to Storable a might be convenient, but this operation is not very commonly needed and a default implementation will probably be both necessary to avoid pointless breakage and a performance foot-gun. (The instances in base would use efficient non-default implementations via new primops, of course.) What do others think?

[Bodigrim]

Isn't readWord8ArrayAsWord64# etc. for unaligned access?

[clyring]

Isn't readWord8ArrayAsWord64# etc. for unaligned access?

Yes, but these are only available when working with ByteArray# and no Addr# counterparts exist at the moment.

[cartazio]

One issue with this is that unaligned read support is platform dependent. So it really first needs to be supported on the ghc primop side. It sounds like a relatively reasonable feature request there perhaps.

What’s your use case? In the mean time, it should be pretty easy to implement such a primop via the c ffi for your engineering needs.

[Bodigrim]

@clyring I'm afraid I have to ask you to come up with a specific proposal to discuss, or mark the issue as abandoned / withdrawn.

I'd personally start with small steps, introducing primops first.

[clyring]

Introducing such primops is in my todo list, but I have enough open ghc branches at the moment. Feel free to mark this as dormant.

[Bodigrim]

Thanks, closing as dormant. Feel free to reopen, once active again.

[oberblastmeister]

@Bodigrim I implemented these primops in ghc https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10614. Please reopen.

[cartazio]

I’m a little confused about the chosen names for the primops. But to be clear: we are talking about byte aligned reads and writes even when we say unaligned?

Also this doesn’t need clc feedback because it’s not in base.

[bgamari]

While these primops are defined in ghc-prim, we want to ensure they will be available via base:GHC.Exts. Consequently, this does require a proposal.

The concrete proposal is something like the following:

GHC.Exts exposes a set of new functions:

indexWord8OffAddrAs<ty> :: Addr# -> Int# -> <ty>#
readWord8OffAddrAs<ty> :: Addr# -> Int# -> State# s -> (# State# s, <ty># #)
writeWord8OffAddrAs<ty> :: Addr# -> Int# -> {rep_ty} -> State# s -> State# s

where <ty> is one of:

• Word
• Word{8,16,32,64}
• Int
• Int{8,16,32,64,}
• Char
• WideChar
• Addr
• Float
• Double
• StablePtr

@oberblastmeister , perhaps you could take the above text, amend it to your liking, and open a new issue in this repository?