via-C

[John Meacham]

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