GHC Extensibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

GHC Extensibility

Monique
Hi (this message is mainly intended to the GHC Team),

 is there any plan to improve GHC's extensibility by providing a
simpler way to integrante new backends?  I worked at Haskell.NET
project in the past, when we integrated successfully a .NET code
generator to GHC 6.2.2.  As it wasn't stable enough, we didn't
integrate it to the main branch.
 However, I've been trying to integrate our code generator to 6.6.1
and I've not been able to compile it up to now, due to several changes
in GHC's code!  I haven't yet figured out how to call the .NET code
generator from GHC 6.6.1's main function.  Further, it would be great
if there was a better extensibility mechanism (such as a "plugin"
infrastructure, for example)  in which it wasn't necessary to use
"#ifdef"along the code.  Also, it would be very useful if this
mechanism/API was well documented.
 Of course, this is only a suggestion.

Best regards.


--
__________________________________________________________
Monique Monteiro, MSc
MCP .NET Framework 2.0 / SCJP / IBM OOAD
Project Manager
Recife Microsoft Innovation Center
+55 81 34198137
http://www.cin.ufpe.br/~mlbm
http://thespoke.net/blogs/moniquelouise/default.aspx
[hidden email]
MSN: [hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extensibility

Brian Alliet
On Wed, May 30, 2007 at 11:45:33AM -0300, Monique Monteiro wrote:
> simpler way to integrante new backends?  I worked at Haskell.NET
> project in the past, when we integrated successfully a .NET code
> generator to GHC 6.2.2.  

Do you have any documentation or papers or anything about your .NET
codegen? Is it the same (somewhat bitrotted) ILX codegen that exists in
the current GHC tree? I'm actually working on a new GHC backend too and
would be interested seeing yours.

> in GHC's code!  I haven't yet figured out how to call the .NET code
> generator from GHC 6.6.1's main function.

You'll probably want to look at hscCompile in main/HscMain.lhs. From
there you can pick up either the Core, Core-Prepped, or STG
representation of the module and pass it off to your backend. If by
chance you want the C-- rep (although that probably won't be too useful
for a .NET backend) you'll want codeOutput in main/CodeOutput.lhs.

-Brian
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extensibility

Monique
Hi Brian,

  the documentation is available at
http://php.cin.ufpe.br/~haskell/haskelldotnet/hsharp.php?m=references
.  It has nothing to do with ILX code generator.  ILX codegen was an
old project run by Don Syme ([hidden email]).

Thanks,

Monique

On 5/30/07, Brian Alliet <[hidden email]> wrote:

> On Wed, May 30, 2007 at 11:45:33AM -0300, Monique Monteiro wrote:
> > simpler way to integrante new backends?  I worked at Haskell.NET
> > project in the past, when we integrated successfully a .NET code
> > generator to GHC 6.2.2.
>
> Do you have any documentation or papers or anything about your .NET
> codegen? Is it the same (somewhat bitrotted) ILX codegen that exists in
> the current GHC tree? I'm actually working on a new GHC backend too and
> would be interested seeing yours.
>
> > in GHC's code!  I haven't yet figured out how to call the .NET code
> > generator from GHC 6.6.1's main function.
>
> You'll probably want to look at hscCompile in main/HscMain.lhs. From
> there you can pick up either the Core, Core-Prepped, or STG
> representation of the module and pass it off to your backend. If by
> chance you want the C-- rep (although that probably won't be too useful
> for a .NET backend) you'll want codeOutput in main/CodeOutput.lhs.
>
> -Brian
>


--
__________________________________________________________
Monique Monteiro, MSc
MCP .NET Framework 2.0 / SCJP / IBM OOAD
Project Manager
Recife Microsoft Innovation Center
+55 81 34198137
http://www.cin.ufpe.br/~mlbm
http://thespoke.net/blogs/moniquelouise/default.aspx
[hidden email]
MSN: [hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: GHC Extensibility

Simon Peyton Jones
In reply to this post by Monique
|  is there any plan to improve GHC's extensibility by providing a
| simpler way to integrante new backends?  I worked at Haskell.NET
...
| in GHC's code!  I haven't yet figured out how to call the .NET code
| generator from GHC 6.6.1's main function.  Further, it would be great
| if there was a better extensibility mechanism (such as a "plugin"
| infrastructure, for example)  in which it wasn't necessary to use
| "#ifdef"along the code.  Also, it would be very useful if this

Yes, good idea.  I think the Right Way to do this is by elaborating the GHC API.  At the moment it has a baked-in way of generating output files, but presumably by elaborating the interface one could allow either
a) GHC returns some Core, and you finish the job, or
b) you give to GHC a function to use for code generation


This requires design work on the GHC API.  As I remarked a couple of days ago, there's a chicken and egg problem with the GHC API.  We have not been working hard on the API because we don't have lots of evidence of strong demand. And since it doesn't do today what you want, you find another way round.

One good thing might be for someone to coordinate a set of use-cases. "We'd like to do X and Y and Z with the GHC API."  I'm thinking pretty specific stuff, with rough type signatures etc, not just "the GHC API should support .net" or "should support dynamic linking".    And names of the protagonists who can amplify.

Next, we'd want to do some API design: just what interface would be good for users?

None of this requires GHC HQ to be on the critical path -- and we know that putting us in the critical path slows processes down!   It'd be sensible for us to comment early and often on the practicality of various possible proposed APIs, and I think we can do that.  But we don't need to drive the process.

Does that sound interesting in principle?  i.e. are there half a dozen people who would like to use the GHC API if only it did X?  (Or did Y better.)  If so, would you like to get together and follow the sequence above?

I know that you all have day jobs too!  But I feel bad that we often no-op on good suggestions because there are Too Many Things To Do To GHC, so it makes sense to maximise opportunities for other people to play a leading role.

Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extensibility

Monique
On 5/30/07, Simon Peyton-Jones <[hidden email]> wrote:

> |  is there any plan to improve GHC's extensibility by providing a
> | simpler way to integrante new backends?  I worked at Haskell.NET
> ...
> | in GHC's code!  I haven't yet figured out how to call the .NET code
> | generator from GHC 6.6.1's main function.  Further, it would be great
> | if there was a better extensibility mechanism (such as a "plugin"
> | infrastructure, for example)  in which it wasn't necessary to use
> | "#ifdef"along the code.  Also, it would be very useful if this
>
> Yes, good idea.  I think the Right Way to do this is by elaborating the GHC API.  > At the moment it has a baked-in way of generating output files, but presumably > > by elaborating the interface one could allow either
> a) GHC returns some Core, and you finish the job, or
> b) you give to GHC a function to use for code generation

I think b) would be a more elegant option.  Further, in Haskell.NET's
current implementation, we receive the STG tree.

Another question: was there any significant optimization or
performance change in the front-end (ie.: generation of Core/STG tree)
since GHC 6.2.2?

Monique

__________________________________________________________
Monique Monteiro, MSc
MCP .NET Framework 2.0 / SCJP / IBM OOAD
Project Manager
Recife Microsoft Innovation Center
+55 81 34198137
http://www.cin.ufpe.br/~mlbm
http://thespoke.net/blogs/moniquelouise/default.aspx
[hidden email]
MSN: [hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: GHC Extensibility

Simon Peyton Jones
| Another question: was there any significant optimization or
| performance change in the front-end (ie.: generation of Core/STG tree)
| since GHC 6.2.2?

Well, I think the core code is a bit better (i.e. more optimised) but it's the same old Core.

Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extensibility

Monique
Hi all,

  I'm able to compile the .NET code generator with GHC without
compiler errors, but now I have the linkage error below.  (In fact
there are other similar messages, this is only an example).  This is
strange because the *.o/*.hi files were all generated without error
messages.  Has anyone any idea about how to solve it?

(...)
stage1/ilGen/ILGen.o(.rodata+0x50):fake: undefined reference to `mtlzm1zi0zi1_C
ntrolziMonadziStateziLazzy_zdf14_closure'
stage1/ilGen/ILGen.o(.rodata+0x68):fake: undefined reference to `mtlzm1zi0zi1_C
ntrolziMonadziStateziLazzy_zdf14_closure'
stage1/ilGen/ILGen.o(.rodata+0x74):fake: undefined reference to `mtlzm1zi0zi1_C
ntrolziMonadziStateziLazzy_zdf14_closure'
stage1/ilGen/ILGen.o(.rodata+0x88):fake: undefined reference to `mtlzm1zi0zi1_C
ntrolziMonadziStateziLazzy_zdf14_closure'
stage1/ilGen/ILGen.o(.rodata+0xb8):fake: more undefined references to `mtlzm1zi
zi1_ControlziMonadziStateziLazzy_zdf14_closure' follow
stage1/ilGen/ILGen.o(.rodata+0x32bc):fake: undefined reference to `mtlzm1zi0zi1
ControlziMonadziStateziLazzy_evalState_closure'
stage1/ilGen/ILGen.o(.rodata+0x32d0):fake: undefined reference to `mtlzm1zi0zi1
ControlziMonadziStateziLazzy_zdf14_closure'
collect2: ld returned 1 exit status
<<ghc: 19046880 bytes, 6 GCs, 176570/181504 avg/max bytes residency (2 samples)
 16M in use, 0.03 INIT (0.00 elapsed), 0.06 MUT (5.61 elapsed), 0.02 GC (0.03 e
apsed) :ghc>>
make: *** [stage1/ghc] Error 1

Monique
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extensibility

Esa Ilari Vuokko
Hi,

On 6/3/07, Monique Monteiro <[hidden email]> wrote:

> Hi all,
>
>   I'm able to compile the .NET code generator with GHC without
> compiler errors, but now I have the linkage error below.  (In fact
> there are other similar messages, this is only an example).  This is
> strange because the *.o/*.hi files were all generated without error
> messages.  Has anyone any idea about how to solve it?
>
> (...)
> stage1/ilGen/ILGen.o(.rodata+0x50):fake: undefined reference to `mtlzm1zi0zi1_C
> ntrolziMonadziStateziLazzy_zdf14_closure'

It seems to me, that the code in ILGen is using Control.Monad.State
(that nowdays defaults to .Lazy) from package mtl.

For stage1, this can be solved by adding "-package mtl" to ghc command
used to linking, for next stages, you'd need to add mtl to bootstrap cycle,
I think.  I have no idea how that is done.  Borrowing code from mtl might be
easier.

HTH,
Esa
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extensibility

Monique
On 6/2/07, Esa Ilari Vuokko <[hidden email]> wrote:
> For stage1, this can be solved by adding "-package mtl" to ghc command
> used to linking, for next stages, you'd need to add mtl to bootstrap cycle,
> I think.  I have no idea how that is done.  Borrowing code from mtl might be
> easier.

GHC gives "unknown package: mtl" when I add this option.  Should I
download it separately?

--
__________________________________________________________
Monique Monteiro, MSc
MCP .NET Framework 2.0 / SCJP / IBM OOAD
Project Manager
Recife Microsoft Innovation Center
+55 81 34198137
http://www.cin.ufpe.br/~mlbm
http://thespoke.net/blogs/moniquelouise/default.aspx
[hidden email]
MSN: [hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: GHC Extensibility

Esa Ilari Vuokko
On 6/3/07, Monique Monteiro <[hidden email]> wrote:
> On 6/2/07, Esa Ilari Vuokko <[hidden email]> wrote:
> > For stage1, this can be solved by adding "-package mtl" to ghc command
> > used to linking, for next stages, you'd need to add mtl to bootstrap cycle,
> > I think.  I have no idea how that is done.  Borrowing code from mtl might be
> > easier.
>
> GHC gives "unknown package: mtl" when I add this option.  Should I
> download it separately?

Maybe it needs version as well, mtl-1.0.1.  You should have the package already
as you managed to compile the haskell files.

Best regards,
Esa

PS. The symbol names are partly z-encoded (you can find details in
ghc sources) and partly contain compiler's invented bits.

mtlzm1zi0zi1_ControlziMonadziStateziLazzy_zdf14_closure becomes

mtl       => mtl    (ie package name)
zm       => -       (dash to separate package name and version)
1zi0zi1 => 1.0.1 (version)
_          => Some convention to put _ there.
ControlziMonadziStateziLazzy
            => Control.Monad.State.Lazy (module)
_zdf14_closure
            => closure number 14 (number is rather arbitary)
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users