Simon Peyton-Jones wrote:
| [...] put a static table in the executable with
| information about register and stack usage indexed by procedure return
| point, and use that to unwind the stack and find roots.
Every accurate garbage collector (including GHC's) uses a technique like
this, but the
Another shortcoming is that the native code generator in GHC isn't
capable of dealing with backward jumps to labels (because GHC hasn't
needed that so far). But if you did C-- optimisation, you'd probably
generate such jumps. It'd be great to beef up the native code gen to
handle that.
I'm alr
Hello Lemmih,
Friday, February 24, 2006, 8:55:37 PM, you wrote:
>> x :: ![Int]
>>
>> translates to the
>>
>> data StrictList a = Nil | Cons a !(StrictList a)
>> x :: !(StrictList a)
L> Let's try this:
L> x :: ![Int] -> Int
L> It would translate to something like this:
L> mkStrictList :: [a] -
On 2/24/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> Hello Lemmih,
>
> Friday, February 24, 2006, 1:15:51 PM, you wrote:
>
> >> clean differs from Haskell in support of unique types and strictness
> >> annotations. the last is slowly migrates into GHC in form of shebang
> >> patters, but i thin
Hello Lemmih,
Friday, February 24, 2006, 1:15:51 PM, you wrote:
>> clean differs from Haskell in support of unique types and strictness
>> annotations. the last is slowly migrates into GHC in form of shebang
>> patters, but i think that it is a half-solution. i mentioned in
>> original letter my
Rene de Visser wrote:
Integer is about 30 times slower than it needs to be on GHC if you have
over half the values between 2^-31 and 2^31. On i386 can you basically
can test the low bit for free (it runs in parallel to the integer add
instruction). This would allow only values outside this rang
| i have found my investiations in this area. that is the C-- code
| generated for fac worker:
|
| Fac_zdwfac_entry() {
| c1C0:
| _s1BD = I32[Sp + 0];
| if (_s1BD != 1) goto c1C4;
| R1 = I32[Sp + 4];
| Sp = Sp + 8;
| jump (I32[Sp + 0]);
| c1C4:
|
Bulat Ziganshin wrote:
i propose to do for start rather small change that will allow to
make things go several times faster and in particular outperform jhc
for the small "leaf" loops (i.e. loops that use only GHC primitives
and don't call other functions). that include factorial, "a[]+=b[i]"
lo
Hello Bulat,
Friday, February 24, 2006, 6:37:42 PM, you wrote:
SPJ>> Perhaps you may consider doing this transformation on the C-- data type
SPJ>> only, without involving the (already very complicated) STG -> C-- code
SPJ>> generator?
i have found my investiations in this area. that is the C-- c
A freshly installed GHC 6.4.1 on my colleague's PC crashes when I try
to build a package:
runhaskell Setup.hs build
The effect is easily reproduceable (it shows up on *any* package
that I try to build).
Does anyone have any idea of what might be wrong here?
Cyril
___
For the record, the inform
Hello glasgow-haskell-users,
i propose to do for start rather small change that will allow to
make things go several times faster and in particular outperform jhc
for the small "leaf" loops (i.e. loops that use only GHC primitives
and don't call other functions). that include factorial, "a[]+=b[i]
| The closest thing I've seen to a solution is the technique used in
Urban
| Boquist's thesis, which is to put a static table in the executable
with
| information about register and stack usage indexed by procedure return
| point, and use that to unwind the stack and find roots.
Every accurate g
On 2/24/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> Hello kyra,
>
> Friday, February 24, 2006, 12:37:02 AM, you 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 advan
Hi Bulat,
Wow! You make a lot of good suggestions. I think some of them are
unfortunately unworkable, some others have been tried before, but there
are definitely some to try. I'll suggest a few more in this email.
First of all I should say that we don't *want* to use gcc as a code
genera
| 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 d
Hello Jean-Philippe,
Friday, February 24, 2006, 2:04:57 AM, you wrote:
JPB> From my (limited) knowledge of GHC backend, the difficult part of your
JPB> plan is that STG is not suited to compilation to native C at all. You
JPB> might need to do quite advanced translation from STG to another
JPB> i
Hello Ben,
Friday, February 24, 2006, 2:04:26 AM, you wrote:
>> * multiple results can be returned via C++ pair template, if this is
>> efficiently implemented in gcc
BRG> There's a -freg-struct-return option in 2.x, 3.x and 4.x. I think it's off
BRG> by default on many architectures.
thank you
Hello kyra,
Friday, February 24, 2006, 12:37:02 AM, you 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
k> no strategies, plain exponential algorithm,
18 matches
Mail list logo
