The following link gives reasons for not generating via C
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
Naturally a number of these are common lisp specific, however I think that
Haskell and GCC are quite semantically different, so using GCC might
Hello Rene,
Thursday, February 23, 2006, 4:19:15 PM, you wrote:
RdV The following link gives reasons for not generating via C
RdV
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
i read it now
RdV Naturally a number of these are common lisp specific,
seems that you don;t understand the situation. ghc compiles Haskell to
language called core, do almost all optimizations at level of this
language, then translates final result to the STG language from that
the C-- code is generated. changing the translation of STG can't
prevent ANY ghc
Bulat Ziganshin wrote:
i think that ocaml can't generate code better than gcc and especially
icc (intel C/C++ compiler), but may be i'm wrong? ;)
didn't try factorial, but exponential fib in ocaml is *FASTER* than both
gcc and intel c/c++ with highest optimization levels
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code usually written by the C programmers. but
code generated by ghc has
Hello kyra,
Thursday, February 23, 2006, 5:38:54 PM, you wrote:
k Bulat Ziganshin wrote:
i think that ocaml can't generate code better than gcc and especially
icc (intel C/C++ compiler), but may be i'm wrong? ;)
k didn't try factorial, but exponential fib in ocaml is *FASTER* than both
k
Hello Rene,
Thursday, February 23, 2006, 5:32:21 PM, you wrote:
seems that you don;t understand the situation. ghc compiles Haskell to
language called core, do almost all optimizations at level of this
language, then translates final result to the STG language from that
the C-- code is
Hello Rene,
Thursday, February 23, 2006, 4:19:15 PM, you wrote:
RdV The following link gives reasons for not generating via C
RdV
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
i done reading. my question - is YOU read this? the lisp problems have
Claus Reinke writes:
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code usually written by the C programmers. but
Hello Claus,
Thursday, February 23, 2006, 8:56:57 PM, you wrote:
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code
Hello Kevin,
Thursday, February 23, 2006, 9:06:25 PM, you wrote:
KG On a related point, Mercury has two C backends a low level one at the
KG level of GHC's and a high level one. Bulat might want to read this for
KG a description of the high level C implementation:
KG
KG
Bulat Ziganshin writes:
Hello Kevin,
KG Also, ghc used to be faster than gcc for a naive, recursive factorial
KG function (once the cpr analysis and optimisation was added). From
KG what Bulat wrote it seems that gcc got better ...
i don't say that we must compile recursive
From: Bulat Ziganshin [EMAIL PROTECTED]
Hello Rene,
i done reading. my question - is YOU read this? the lisp problems have
almost
nothing in common with haskell
It is a long time since i read this, but some things come to mind. Listed
below.
Maybe GHC should generate better C. I am
Hello Rene,
Thursday, February 23, 2006, 10:17:40 PM, you wrote:
RdV Maybe GHC should generate better C. I am just not sure whether this will
RdV bring the best global (as opposed to micro-optimizations) performance.
i answered in the original letter (search for Cray :)
RdV Generating better C
From: Bulat Ziganshin [EMAIL PROTECTED]
i answered in the original letter (search for Cray :)
Re-reading this, I see that you have a well defined goals that cover most of
my points.
seems that you don't seen the attached files. tail calls are optimized
in gcc
No I don't see any
Bulat Ziganshin wrote:
i prefer to see the asm code. this may be because of better high-level
optimization strategies (reusing fib values). the scheme about i say
will combine advantages of both worlds
no strategies, plain exponential algorithm,
ocaml:
excerpt
_camlFibo__fib_57:
sub
[EMAIL PROTECTED] wrote:
* multiple results can be returned via C++ paira,b template, if this is
efficiently implemented in gcc
There's a -freg-struct-return option in 2.x, 3.x and 4.x. I think it's off
by default on many architectures.
* recursive definitions translated into the for/while
Hello Bulat,
From my (limited) knowledge of GHC backend, the difficult part of your
plan is that STG is not suited to compilation to native C at all. You
might need to do quite advanced translation from STG to another
intemediate language, (as GRIN for example), and then some more
advanced
18 matches
Mail list logo
