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 native
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 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
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 the
* 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 comparison is present
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:
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 side
conditions that
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
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
This paper
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
* 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 pool base
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 interest
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.
In both cases,
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)
14 matches
Mail list logo
