#4102: Bit manipulation built-ins
---------------------------------+------------------------------------------
Reporter: uzytkownik | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 6.16.1
Component: libraries/base | Version: 6.12.2
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by uzytkownik):
Replying to [comment:6 gwicke]:
> Replying to [comment:5 uzytkownik]:
> > I would strongly suggest Data.Bits for the following reasons:
> >
> > - All of them can be implemented in terms of the Data.Bits
primitives. It is simply an extention for specialization.
> > - They should be handled in-line by compiler as for many
architectures they can be optimized to single instruction. LLVM inline
shoul handle it perfectly.
>
> Is it possible to do this optimization without requiring new primops and
have it work across GHC backends? Could this be implemented using rules?
>
Well. Yes as long as rules would allow LLVM assambly or GHC would perform
link-time LLVM optimalization for FFI.
One could easily extend Data.Bits and provide default implementations (it
would break nothing). However GHC can provide (possibly it would require
small work for each backend) it's own implementations - (.&.) is not
implemented for Int/Int8/16/32/64 etc. anyway.
> My package is just a stop-gap measure to get access to native
instructions, so I do not think this code would be suitable for Data.Bits.
Maybe- if there is a way to use e.g. CPP to select the implementation by
backend- some of this code could be used in the -fvia-C or -fasm
implementations.
I fully understend. However I belive that putting it outside Data.Bits
would:
- Make little sense as they are bits operation. Just more optimized
version of code
- Make harder for custom types to optimize them
I would really like to see them 'native' - however your package is great
when they are not native.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4102#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
