d M Peixotto
Date: Wed Oct 19 15:49:06 2011 -0500
Change stack alignment to 16+8 bytes in STG code
This patch changes the STG code so that %rsp to be aligned
to a 16-byte boundary + 8. This is the alignment required by
the x86_64 ABI on entry to a function. Previously we kept
%
On 2/21/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> | Working on the documentation and external tools (with help from Andrew
> | Tolmach) is my priority right now, as I need it for my own work. Thus
> | *generating* External Core (and parsing it back in with an external
> | tool) should
| Working on the documentation and external tools (with help from Andrew
| Tolmach) is my priority right now, as I need it for my own work. Thus
| *generating* External Core (and parsing it back in with an external
| tool) should be possible for mere mortals again soon.
OK that's excellent. Thank
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> Sorry, I should have been more precise. The language definition does not
> say anything about the pragmas and GHC ignores them by default. However,
> GHC has a flag which tells it to assign a meaning to certain pragmas.
> With this flag
Tim Chevalier wrote:
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
If it can't or doesn't want to maintain it, it throws it away. The info
is optional: if it's there, it has to be correct but it doesn't have to
be there.
[snip]
Just like in Haskell, they don't have a semantics -
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
>
> If it can't or doesn't want to maintain it, it throws it away. The info
> is optional: if it's there, it has to be correct but it doesn't have to
> be there.
[snip]
>
> Just like in Haskell, they don't have a semantics - they are essen
Tim Chevalier wrote:
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
Tim Chevalier wrote:
>
> 2) Perhaps even more seriously, GHC keeps a great deal of analysis
> information attached to variables, and it doesn't really make sense to
> export much of it into External Core files --
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> Tim Chevalier wrote:
> >
> > 2) Perhaps even more seriously, GHC keeps a great deal of analysis
> > information attached to variables, and it doesn't really make sense to
> > export much of it into External Core files -- external tools
Tim Chevalier wrote:
2) Perhaps even more seriously, GHC keeps a great deal of analysis
information attached to variables, and it doesn't really make sense to
export much of it into External Core files -- external tools
presumably mostly can't or don't want to make usage of strictness
informatio
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> Tim Chevalier wrote:
> >
> > Working on the documentation and external tools (with help from Andrew
> > Tolmach) is my priority right now, as I need it for my own work. Thus
> > *generating* External Core (and parsing it back in with a
Tim Chevalier wrote:
Working on the documentation and external tools (with help from Andrew
Tolmach) is my priority right now, as I need it for my own work. Thus
*generating* External Core (and parsing it back in with an external
tool) should be possible for mere mortals again soon.
That's gre
On 2/19/08, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> The ext-core stuff is more complicated, and the support libraries that
> were meant to exist around it have all bit-rotted in nasty ways. As it
> currently stands, Tim's work is about the easiest route to getting
> Core out of GHC, but is fairl
On 2/19/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>
>
>
>
> It relates to strictness info etc. I strongly suggest you do not try to
> parse this stuff -- it was never intended for that. Why do you think
> ext-core is harder? It's designed to be easier!
>
While I agree that there doesn't
On 2/18/08, Guilherme Avelino <[EMAIL PROTECTED]> wrote:
> I started my project implementing a stg compiler to .NET, as described in
> "Implementing Lazy Functional Languages on Stock Hardware: The Spineless
> Tagless G-Machine" [Jones, Peyton]. After that, I resolved to integrate it
> to GHC, so I
Hi Simon,
> It relates to strictness info etc. I strongly suggest you do not try to
> parse this stuff -- it was never intended for that. Why do you think
> ext-core is harder? It's designed to be easier!
The ext-core stuff is more complicated, and the support libraries that
were meant to exist
2008 11:08
To: Cvs-ghc@haskell.org
Subject: Re: STG code
Hi, I´m trying to use the Core representation by -ddump-simpl, because the code
generated is simpler than -fext-core.
But I don´t understand the meaning of some informations.
I compile the code:
mapp::(t->u)->[t]->[u]
mapp _
Sorry, I put the wrong code. The generated code is:
Rec {
Teste.mapp :: forall t_a5D u_a5E. (t_a5D -> u_a5E) -> [t_a5D] -> [u_a5E]
[GlobalId]
[Arity 2
NoCafRefs
Str: DmdType LS]
Teste.mapp =
\ (@ t_aap) (@ u_aaq) (ds_dat :: t_aap -> u_aaq) (ds1_dau :: [t_aap]) ->
case ds1_dau of wild_B1 {
Hi, I´m trying to use the Core representation by -ddump-simpl, because the
code generated is simpler than -fext-core.
But I don´t understand the meaning of some informations.
I compile the code:
mapp::(t->u)->[t]->[u]
mapp _ [] = []
mapp f (x:xs) = (f x):(mapp f xs)
is generated:
Teste.t :: G
On 2/18/08, Guilherme Avelino <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I know that Stg don´t have type informations, but I saw some research using
> a changed version of GHC
>
> Some researches, like Compiling Haskell to Java [Tullsen, Mark] and
> Multi-Paradigm Just-In-Time Compilation [Stewart, Don]
Hi,
I know that Stg don´t have type informations, but I saw some research using
a changed version of GHC
Some researches, like Compiling Haskell to Java [Tullsen, Mark] and
Multi-Paradigm Just-In-Time Compilation [Stewart, Don], have used the STG as
frontend for them compilers. They changed the
What kind of changes can I expect? Only format changes or changes in the
informations showed. When will be launch the version 6.10?
Thanks!
2007/11/20, Aaron Tomb <[EMAIL PROTECTED]>:
>
> Actually, that file should be fine. I updated the External Core output
> path to include all of the construct
Actually, that file should be fine. I updated the External Core output
path to include all of the constructs in modern GHC core. It's the
input path I've been slow to finish (and, when I do finish it, the
output format will likely be totally different, too :) )
So, there's little formal doc
Hi,
I didn´t understand. I´m using the GHC 6.8.1 and when I use -fext-core is
generated a file (.hcr). Is there any problem with the generated code? Which
version should I use?
Thanks
2007/11/19, Tim Chevalier <[EMAIL PROTECTED]>:
>
> On 11/19/07, Guilherme Avelino <[EMAIL PROTECTED]> wrote:
>
On 11/19/07, Guilherme Avelino <[EMAIL PROTECTED]> wrote:
> I have two questions about the code generated by -fext-core:
>
> Is there one place where I can obtain the grammar for it?
> How is represented the free-vars?
>
See:
"An External Representation for the GHC Core Language" (2001)
Andrew To
ts the "Core" form.
> > This is fully typed, unlike STG code which is only partially typed.
> >
> >
> >
> > If you compile with –fext-core you'll get a printed form which is
> > supposed to be reasonably easy to parse. Tim Chevalier and Aaron Tomb ar
I have two questions about the code generated by -fext-core:
2007/11/19, Simon Peyton-Jones <[EMAIL PROTECTED]>:
>
> I suspect you probably want –ddump-simpl, which prints the "Core" form.
> This is fully typed, unlike STG code which is only partially typed.
>
>
I suspect you probably want -ddump-simpl, which prints the "Core" form. This is
fully typed, unlike STG code which is only partially typed.
If you compile with -fext-core you'll get a printed form which is supposed to
be reasonably easy to parse. Tim Chevalier and Aaron Tomb are
On 11/16/07, Guilherme Avelino <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I want to use the stg code generated by the ghc with a frontend for my
> compiler. I´m using the flags -ddump-stg and -dppr-debug to obtain the STG
> informations. However there are some things that I
stefanor:
> On Fri, Nov 16, 2007 at 05:14:08PM -0300, Guilherme Avelino wrote:
> > Hi,
> >
> > I want to use the stg code generated by the ghc with a frontend for my
> > compiler. I´m using the flags -ddump-stg and -dppr-debug to obtain the STG
> > informatio
On Fri, Nov 16, 2007 at 05:14:08PM -0300, Guilherme Avelino wrote:
> Hi,
>
> I want to use the stg code generated by the ghc with a frontend for my
> compiler. I´m using the flags -ddump-stg and -dppr-debug to obtain the STG
> informations. However there are some things that I d
Hi,
I want to use the stg code generated by the ghc with a frontend for my
compiler. I´m using the flags -ddump-stg and -dppr-debug to obtain the STG
informations. However there are some things that I din´t understand. Are
there any document where I can find informations about the stg generated
31 matches
Mail list logo
