Re: via-C
GHC code still depends on RTS code (written in C by the way) which has to be ported to a specific platform first. Native code generator offers 'registered' and 'unregistered' builds. The first are aware of specific register layout of a architecture. You can find more rationale why it has been removed somewhere on GHC wiki or mailing lists. I think you might be interested in JHC: http://repetae.net/computer/jhc/ By design it compiles Haskell code to efficient C code which is quite easy to read and hack further. Cross compilation is supported and easy too. The compiler is somewhat experimental but can handle quite a few programs. Best regards, Krzysztof Skrzętnicki On Sun, Feb 5, 2012 at 19:48, Serge D. Mechveliani wrote: > Dear GHC team, > > I cannot understand why do you remove the C stage in GHC. > To my mind: let the result be 3 times slower, but preserve the C code. > Because it works everyhere, and there is no real need to rewrite > the same program separately for all the existing processors > (which number may become, for example, 11000). > I am naive, and am not a specialist. > But only an invariant program ever has sense. > > Has the modern GHC a sensible compilation result level to be observed > (documented?) (graph rewriting code, or like this) ? > > Regards, > > -- > Sergei > mech...@botik.ru > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: via-C
Hello, as far as I understand, via-C was removed for registerised builds, but is still supported for unregisterised builds. So if you prefer via-C way, just compile GHC unregistered on your platform. Cheers, Karel On 02/ 5/12 07:48 PM, Serge D. Mechveliani wrote: Dear GHC team, I cannot understand why do you remove the C stage in GHC. To my mind: let the result be 3 times slower, but preserve the C code. Because it works everyhere, and there is no real need to rewrite the same program separately for all the existing processors (which number may become, for example, 11000). I am naive, and am not a specialist. But only an invariant program ever has sense. Has the modern GHC a sensible compilation result level to be observed (documented?) (graph rewriting code, or like this) ? Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: via-C
Being in C is very different than being 'portable'. The C code generated by GHC never looked anything like what you would expect C code to look like, it was basically a list of pre-proccessor macros that expanded to STG-machine code sort of. If you want to know what low-level operations ghc is doing to gauge whether an optimization you are expecting is happening for instance, you are probably better off looking at the core after optimization, it will be closer to your input code and be easier to track the effects of changes in your source code. If you are interested in porting haskell to a new target, then my jhc would probably be useful. it will work on pretty much anything that has a gcc port and people have succeeded in targeting a large diversity of architectures with it. 0.8.0 is coming out soon which even supports targeting even more unusual arches, like 36 bit everythings or an arch with 16 bit ints and 8 bit ascii chars. (unusual as a target for haskell compilers, but fairly common out there in the embedded world) John On Sun, Feb 5, 2012 at 10:48 AM, Serge D. Mechveliani wrote: > Dear GHC team, > > I cannot understand why do you remove the C stage in GHC. > To my mind: let the result be 3 times slower, but preserve the C code. > Because it works everyhere, and there is no real need to rewrite > the same program separately for all the existing processors > (which number may become, for example, 11000). > I am naive, and am not a specialist. > But only an invariant program ever has sense. > > Has the modern GHC a sensible compilation result level to be observed > (documented?) (graph rewriting code, or like this) ? > > Regards, > > -- > Sergei > mech...@botik.ru > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: via-C
On Sun, Feb 05, 2012 at 09:09:58PM +0100, Krzysztof Skrz??tnicki wrote: > GHC code still depends on RTS code (written in C by the way) which has to > be ported to a specific platform first. Native code generator offers > 'registered' and 'unregistered' builds. The first are aware of specific > register layout of a architecture. You can find more rationale why it has > been removed somewhere on GHC wiki or mailing lists. > > I think you might be interested in JHC: http://repetae.net/computer/jhc/ > > By design it compiles Haskell code to efficient C code which is quite easy > to read and hack further. Cross compilation is supported and easy too. The > compiler is somewhat experimental but can handle quite a few programs. > I need a reliable portability for ages for the Haskell applications written in Haskell-2010 + Ext, where Ext = Overlapping instances + Multiparametric classes (as in GHC). In particular, my DoCon is such an application. And no Haskell tool was able to compile DoCon except GHC (I tested this in 1995 - 2000). And now GHC somehow seems to deviate from portability (if I am not missing something, I do not know of the GHC technology details). I suspect that a reliable portability can be done mainly by writing in C an interpreter of the Core language of GHC (no matter if it occurs even 10 times slower). Regards, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: via-C
On Mon, Feb 6, 2012 at 01:05, Serge D. Mechveliani wrote: > And now GHC somehow seems to deviate from portability Registerised GHC was never "portable". Or if it was, it was well before GHC6. You just weren't aware of what was going on, and apparently built yourself a fantasy world where GHC always produced perfectly portable ANSI C code. That's an unregisterised build. It's still there, for portability reasons. It's not three times slower, or ten times slower; for many things, it's several hundred times slower, or worse. But I'm sure even that is not justification for not having been designed specifically with your important needs in mind. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: via-C
On 5 February 2012 10:48, Serge D. Mechveliani wrote: > Dear GHC team, > > I cannot understand why do you remove the C stage in GHC. We didn't. GHC itself can be built in two different ways, 'unregisterized' and 'registerized'. The former method is more portable while the latter uses as many tricks as possible for performance but is quite platform specific. The C backend used to support both ways. Now it only supports unregisterized. It remains specifically for what you want, portability. The NCG of GHC only supports registerized way. The LLVM backend supports both unregisterized and registerized. So take a look at the C backend and LLVM. Cheers, David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: via-C
* Serge D. Mechveliani [2012-02-06 10:05:14+0400] > I need a reliable portability for ages for the Haskell applications > written in Haskell-2010 + Ext, > where Ext = Overlapping instances + Multiparametric classes > (as in GHC). > In particular, my DoCon is such an application. > And no Haskell tool was able to compile DoCon except GHC > (I tested this in 1995 - 2000). > And now GHC somehow seems to deviate from portability > (if I am not missing something, I do not know of the GHC technology > details). If you are not happy with where GHC is going, I suppose you can stick with some old version which satisfies your requirements? It sounds like you don't care much about performance or new features. -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
