
We're already compiling via an intermediate data type that is closely based on C--. That internal data type is used regardless of whether you emit C, asm, or C--. Actually using C-- itself as an output medium keeps slipping down the agenda, mainly because no one asks for it! But I still fully intend to do it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Simon Marlow | Sent: 01 August 2005 13:13 | To: Bulat Ziganshin; glasgow-haskell-users@haskell.org | Subject: RE: C-- | | On 31 July 2005 08:10, Bulat Ziganshin wrote: | | > can you please say about value of using C-- in GHC? will this | > reduce compile time, increase speed of compiled programs, improve | > portability or make some other effect? would the C-- compile path | > replace asm or C path? | | It should reduce compile time compared to compiling via C, though I | suspect it will still be slower than using GHC's built-in native code | generator. | | It should improve the speed of compiled programs, because C-- will be | using its own, efficient, calling convention. For example, this will | mean that some arguments can be passed in registers on x86, which we | can't do currently because of a combination of the lack of registers and | limitations in what we can convince gcc to do. | | It should improve portability, because there is less work in GHC | required to compile via C-- on a new platform: no mangler to modify, for | example. | | Eventually, we hope the registerised via-C path would become redundant. | The unregisterised path is still useful for bootstrapping, given that | more platforms have a C compiler than a C-- compiler (if C-- were to | become ubiquitous, the unregisterised path would become irrelevant too). | | Cheers, | Simon | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hello Simon, Monday, August 08, 2005, 7:17:06 PM, you wrote: SPJ> Actually using C-- itself as an output medium keeps slipping down the SPJ> agenda, mainly because no one asks for it! because you don't advertise it! :) if you will advertise the following, preferably with less or more concrete numbers, then we will know whether we want it or not. just asking "whether you want to have C or C-- compilation path?" is not enough what about C-- compiler? you will use the existing version of Quick C--? is this compiler enough bug-free and generates good enough code? SPJ> | It should reduce compile time compared to compiling via C, though I SPJ> | suspect it will still be slower than using GHC's built-in native code SPJ> | generator. SPJ> | SPJ> | It should improve the speed of compiled programs, because C-- will be SPJ> | using its own, efficient, calling convention. For example, this will SPJ> | mean that some arguments can be passed in registers on x86, which we SPJ> | can't do currently because of a combination of the lack of registers SPJ> and SPJ> | limitations in what we can convince gcc to do. SPJ> | SPJ> | It should improve portability, because there is less work in GHC SPJ> | required to compile via C-- on a new platform: no mangler to modify, SPJ> for SPJ> | example. SPJ> | SPJ> | Eventually, we hope the registerised via-C path would become SPJ> redundant. SPJ> | The unregisterised path is still useful for bootstrapping, given that SPJ> | more platforms have a C compiler than a C-- compiler (if C-- were to SPJ> | become ubiquitous, the unregisterised path would become irrelevant SPJ> too). -- Best regards, Bulat mailto:bulatz@HotPOP.com
participants (2)
-
Bulat Ziganshin
-
Simon Peyton-Jones