Hi, Currently ghc 6.12 does not have support for CLDouble type (and there is an open issue on trac about it http://hackage.haskell.org/trac/ghc/ticket/3353 ). I have been trying to figure out what is necessary to add it. After playing with the code a bit I've got a few questions... 1. Should there be a LDouble type, just like for CFloat and CDouble there there are Haskell-native types Float and Double? 2. The ghc compiler references Float and Double in its code. When a similar code is added for LDouble, the compiler does not get built. In particular, 'compiler/coreSyn/CoreSyn.lhs' does not see 'LDouble' despite I declared and exported it in 'libraries/ghc-prim/GHC/Types.hs'. This probably makes sense in case compiler is built first. But then in turns out to be a chicken and egg situation as to support a new type in GHC one needs to have another GHC that already supports it. Or, perhaps, I am missing something? 3. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/Reg... mentions that there are registers for floats and doubles. What should be done about long doubles then? With kind regards and hope that gurus may shed some light on the above, Denys Rtveliashvili
On 09/01/2010 22:33, Denys Rtveliashvili wrote:
Currently ghc 6.12 does not have support for CLDouble type (and there is an open issue on trac about it http://hackage.haskell.org/trac/ghc/ticket/3353 ).
This is quite a big job, incedentally. Apart from the x86 native code generator the changes will be fairly routine, however.
I have been trying to figure out what is necessary to add it. After playing with the code a bit I've got a few questions...
1. Should there be a LDouble type, just like for CFloat and CDouble there there are Haskell-native types Float and Double?
You will need to add an LDouble# type, and some operations on it - at least conversions to/from Double#, I imagine. In Cmm, you need to add MachOps for the LDouble# operations, and the code generator needs to know about how to shuffle LDouble# values around (how much space they take on the stack and heap, for example).
2. The ghc compiler references Float and Double in its code. When a similar code is added for LDouble, the compiler does not get built. In particular, 'compiler/coreSyn/CoreSyn.lhs' does not see 'LDouble' despite I declared and exported it in 'libraries/ghc-prim/GHC/Types.hs'. This probably makes sense in case compiler is built first. But then in turns out to be a chicken and egg situation as to support a new type in GHC one needs to have another GHC that already supports it. Or, perhaps, I am missing something?
GHC gets built in 2 "stages", stage 1 is built using your installed GHC, the libraries are then built using stage 1, and then stage 2 is built using stage 1 and those libraries. So if you add something to a library, it is only available in stage 2, and you need to use appropriate #ifdefs if it is necessary to use it in GHC itself (although this is generally discouraged if you can avoid it, we try to avoid adding version dependencies to the code if we can).
3. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/Reg... mentions that there are registers for floats and doubles. What should be done about long doubles then?
Registers are not necessary, I believe, Indeed, since there are no registers that hold long doubles on x86 apart from the silly x87 register stack, I don't think it would help to add any register assignments. This means that long doubles will get passed on the stack, but that's not a big deal. Cheers, Simon
participants (2)
-
Denys Rtveliashvili -
Simon Marlow