This code doesn't work:
import System(getArgs)
main = do n <- getArgs >>= readIO.head
putStrLn (show (tak (3*n) (2*n) n))
tak :: Float -> Float -> Float -> Float
tak x y z | y>=x = z
| otherwise = tak (tak (x-1) y z) (tak (y-1) z x) (tak (z-1) x
y
On Wed, 2005-11-02 at 19:47 +0100, Florian Weimer wrote:
> >> It seems that the goto-based version leads to different static branch
> >> prediction results, which happen to be favorable.
> >
> > It has nothing to do with branch prediction. I know
> > it is determined ENTIRELY by stack use.
>
> I
On Wed, 2005-11-02 at 18:05 +0100, Florian Weimer wrote:
> >> Is it correct that you use indirect gotos across functions? Such
> >> gotos aren't supported by GCC and work only by accident.
> >
> > Even direct gotos aren't universally supported. Some info
> > in Fergus Henderson's paper may be of i
* Lennart Augustsson:
> Simon Marlow wrote:
>>>Is it correct that you use indirect gotos across functions? Such
>>>gotos aren't supported by GCC and work only by accident.
>> Yes, but cross-function gotos are always to the beginning of a
>> function.
>
> Is that enough to ensure that the constant
>> It seems that the goto-based version leads to different static branch
>> prediction results, which happen to be favorable.
>
> It has nothing to do with branch prediction. I know
> it is determined ENTIRELY by stack use.
In both cases, The C compiler emits code which doesn't use the stack.
__
Simon Marlow wrote:
Is it correct that you use indirect gotos across functions? Such
gotos aren't supported by GCC and work only by accident.
Yes, but cross-function gotos are always to the beginning of a function.
Is that enough to ensure that the constant pool base register
is reloaded on
>> Is it correct that you use indirect gotos across functions? Such
>> gotos aren't supported by GCC and work only by accident.
>
> Even direct gotos aren't universally supported. Some info
> in Fergus Henderson's paper may be of interest
>
> http://felix.sourceforge.net/papers/mercury_to_c.ps
Th
On Wed, 2005-11-02 at 14:59 +0100, Florian Weimer wrote:
> Is it correct that you use indirect gotos across functions? Such
> gotos aren't supported by GCC and work only by accident.
Even direct gotos aren't universally supported. Some info
in Fergus Henderson's paper may be of interest
http:/
* Simon Marlow:
>> However, beginning with GCC 3.4, you can use:
>>
>> extern void bar();
>>
>> void foo()
>> {
>> void (*p)(void) = bar;
>> p();
>> }
>
> Interesting.. though I'm not sure I'm comfortable with relying on gcc's
> tail call optimisation to do the right thing. Aren't there sid
On 02 November 2005 13:59, Florian Weimer wrote:
> However, beginning with GCC 3.4, you can use:
>
> extern void bar();
>
> void foo()
> {
> void (*p)(void) = bar;
> p();
> }
Interesting.. though I'm not sure I'm comfortable with relying on gcc's
tail call optimisation to do the right thing
* Simon Marlow:
>>> gcc started generating this rubbish around version 3.4, if I recall
>>> correctly. I've tried disabling various optimisations, but can't
>>> seem to convince gcc not to generate the extra jump. You don't get
>>> this from the native code generator, BTW.
>>
>> But the compari
On 02 November 2005 11:15, Rene de Visser wrote:
> Where is the documentation on how pinning works in the GHC garbage
> collector (from a GHC users point of view).
>
> I have copied the following code from array/IO.hs and am thinking
> that it is assuming that the array is pinned? What triggers t
On Wed, 2 Nov 2005, skaller wrote:
> On Tue, 2005-11-01 at 19:03 +0100, Florian Weimer wrote:
>
> > BTW, you shouldn't generate identifiers with leading underscores
> > because they are reserved for the implementation.
>
> I AM the implementation :)
You are not the C implementation.
> Generated I
Hello,
Where is the documentation on how pinning works in the GHC garbage collector
(from a GHC users point of view).
I have copied the following code from array/IO.hs and am thinking that it is
assuming that the array is pinned? What triggers the pinning?
On a second note.
Why is the type
On 01 November 2005 16:32, Florian Weimer wrote:
> * Simon Marlow:
>
>> gcc started generating this rubbish around version 3.4, if I recall
>> correctly. I've tried disabling various optimisations, but can't
>> seem to convince gcc not to generate the extra jump. You don't get
>> this from the
15 matches
Mail list logo
