New primitive types?

Carter Schonwald carter.schonwald at
Tue Aug 1 18:07:49 UTC 2017

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

On Tue, Aug 1, 2017 at 9:37 AM Michal Terepeta <michal.terepeta at>

> Hi all,
> I'm working on making it possible to pack constructor fields [1],
> example:
> ```
> data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32
> ```
> should only require 4 bytes for unpacked `Float` and 4 bytes for
> unpacked `Int32`, which on 64-bit arch would take just 1 word (instead
> of 2 it currently does).
> The diff to support packing of fields is in review [2], but to really
> take advantage of it I think we need to introduce new primitive types:
> - Int{8,16,32}#
> - Word{8,16,32}#
> along with some corresponding primops and with some other follow-up
> changes like extending `PrimRep`.
> Then we could use them in definitions of `Int{8,16,32}` and
> `Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`).
> Does that sound ok with everyone? (just making sure that this makes
> sense before I invest more time into this :)
> Thanks,
> Michal
> [1]
> [2]
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list