On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald wrote:

One issue with packed fields is that on many architectures you can't quite do subword reads or writes. So it might not always be a win.

There's also the issue that c-- as it exists in ghc doesn't have any notion of subword sized types.

That said, I do support making word/int64/32 # types more first class / built in. (I hit some issues which tie into this topic in the process of working on my still in

Could you give any examples? Note that we're still going to do aligned read/writes, i.e., `Int32#` would still be 4 bytes aligned, `Int16#` 2 bytes, etc. So we might have "holes", e.g., `data Foo = Foo Int8# Int64#` would still waste 7 bytes (since `Int64#` should be 8 bytes aligned). In the future, I'd also like to do some field reordering to avoid some holes like that in cases like `Foo Int32# Int64# Int32#` (here it'd be better if the in-memory layout was `Int64#` first and then the two `Int32#`s) progress safeword

package. )

Point being: I support improving what we have, but it's got a bit of surface area. Please let me know how I can help you dig into this though

Have a look at https://ghc.haskell.org/trac/ghc/ticket/13825 which tracks the progress. The most recent diff is https://phabricator.haskell.org/D3809 So far, most of this work is based on some unfinished code by Simon Marlow to support storing constructor fields smaller than words. I'm currently mostly finishing/fixing it and splitting to smaller pieces. Introducing more primitive stuff is the next step. (assuming everyone is ok with this :) Cheers, Michal

Which architectures are which? I assume you mean the dec alpha allowed atomic operations on bytes... but your phrasing is a teeny bit unclear On Sat, Aug 19, 2017 at 4:34 AM Florian Weimer wrote:

* Michal Terepeta:

...

On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

One issue with packed fields is that on many architectures you can't quite do subword reads or writes. So it might not always be a win.

Could you give any examples?

Historic DEC Alpha, now long obsolete.

It is very hard to create compliant and performant implementations of Java 5, C 11 or C++ 11 on such architectures. All these languages (and their subsequent revisions) require that naturally aligned objects can be accessed independently. For example, you can't use a simple read-modify-write cycle to implement a single-byte store using word operations.

That's why such architectures really do not have a future (or even a present), except maybe in niche markets such as GPGPU (but even there, things are heading towards the de-facto standard memory model).

I think it should be mostly fine... memory alignment is my main bugbear of a worry, but I guess that requires experimentation 😊😊 On Sun, Aug 27, 2017 at 6:50 PM Michal Terepeta wrote:

...

On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry wrote: Hi,

I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc.

Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal.

Ok, a short proposal sounds reasonable.

I don't think this would break a lot of code - based on a few searches it seems that people don't really extract `Int#` from `Int8/Int16/Int32` (similarly with words). Or am I missing something?

Thanks, Michal

PS. Sorry for slow reply - I was traveling.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs