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 analys
[EMAIL PROTECTED] wrote:
* multiple results can be returned via C++ pair 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 loo
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:
_camlFibo__fib_57:
subesp, 8
L101
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 atta
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 bett
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 ju
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 r
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> http://www.cs.mu.o
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 co
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 programmer
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=en&lr=&ie=UTF-8&selm=4zp8kn7xe.fsf_-_%40beta.franz.com
i done reading. my question - is YOU read this? the lisp problems have a
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 i
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 b
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 nothing
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
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 optimi
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=en&lr=&ie=UTF-8&selm=4zp8kn7xe.fsf_-_%40beta.franz.com
i read it now
RdV> Naturally a number of these are common lisp specific,
The following link gives reasons for not generating via C
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=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 pre
Hello
last days i studied GHC code generator, reading -ddumps of all sorts,
GHC sources, various papers and John's appeals :)
what i carried from this investigation:
GHC has great high-level optimization. moreover, GHC now allows to
program STG almost directly. when i look at STG code i don't se
19 matches
Mail list logo
