<div dir="ltr"><div><div>On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:</div><div>> One issue with packed fields is that on many architectures you can't quite do subword reads or</div><div>> writes.  So it might not always be a win.  </div><div><br></div><div>Could you give any examples?</div><div><br></div><div>Note that we're still going to do aligned read/writes, i.e., `Int32#`</div><div>would still be 4 bytes aligned, `Int16#` 2 bytes, etc. So we might</div><div>have "holes", e.g., `data Foo = Foo Int8# Int64#` would still waste 7</div><div>bytes (since `Int64#` should be 8 bytes aligned).</div><div><br></div><div>In the future, I'd also like to do some field reordering to avoid some</div><div>holes like that in cases like `Foo Int32# Int64# Int32#` (here it'd be</div><div>better if the in-memory layout was `Int64#` first and then the two</div><div>`Int32#`s)</div><div><br></div><div>> There's also the issue that c-- as it exists in ghc doesn't have any notion of subword sized</div><div>> types.  </div><div>></div><div>> That said, I do support making word/int64/32 # types more first class / built in.  (I hit some</div><div>> issues which tie into this topic in the process of working on my still in progress safeword</div><div>> package. )</div><div>></div><div>> Point being: I support improving what we have, but it's got a bit of surface area.  Please let me</div><div>> know how I can help you dig into this though </div><div><br></div><div>Have a look at <a href="https://ghc.haskell.org/trac/ghc/ticket/13825">https://ghc.haskell.org/trac/ghc/ticket/13825</a> which</div><div>tracks the progress. The most recent diff is</div><div><a href="https://phabricator.haskell.org/D3809">https://phabricator.haskell.org/D3809</a></div><div><br></div><div>So far, most of this work is based on some unfinished code by Simon</div><div>Marlow to support storing constructor fields smaller than words.  I'm</div><div>currently mostly finishing/fixing it and splitting to smaller pieces.</div><div>Introducing more primitive stuff is the next step. (assuming everyone</div><div>is ok with this :)</div><div><br></div><div>Cheers,</div><div>Michal<br></div></div><div><br></div></div>