
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 mechvel@botik.ru

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
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 mechvel@botik.ru
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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 mechvel@botik.ru

On Mon, Feb 6, 2012 at 01:05, Serge D. Mechveliani
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 allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

* Serge D. Mechveliani
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/

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 mechvel@botik.ru
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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
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 mechvel@botik.ru
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On 5 February 2012 10:48, Serge D. Mechveliani
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
participants (7)
-
Brandon Allbery
-
David Terei
-
John Meacham
-
Karel Gardas
-
Krzysztof Skrzętnicki
-
Roman Cheplyaka
-
Serge D. Mechveliani