Thanks. This is beyond my competence, and I'm totally submerged anyway. I suggest you make a Trac ticket about it anyway. Simon Marlow will probably have an opinion. Simon | -----Original Message----- | From: Sergei Trofimovich [mailto:slyich@gmail.com] | Sent: 16 September 2014 19:03 | To: Simon Peyton Jones | Cc: Norman Ramsey; ghc-devs; Simon Marlow | Subject: Re: cminusminus.org does not have a link to the spec | | On Mon, 15 Sep 2014 12:05:27 +0000 | Simon Peyton Jones wrote: | | My planned change is for GHC's .cmm files syntax/codegen. | The idea came out after having stumbled upon a rare ia64 | bug in GHC's C codegen: | | | http://git.haskell.org/ghc.git/commitdiff/e18525fae273f4c1ad8d6cbe1dea4fc | 074cac721 | | The fundamental bug here is the following: | Suppose we have two bits of rts: one .c file and one .cmm file | | // rts.c defines and exports a function and a variable | void some_rts_fun (void); | int some_rts_var; | | // rts.cmm uses rts.c's function and variable | import some_rts_fun; /* this forces C codegen to emit function-like | 'StgFunPtr some_rts_fun ();' | prototype, it's fine */ | | import some_rts_var; /* also forces C codegen to emit function-like | 'StgFunPtr some_rts_var ();' | prototype, it's broken */ | // ... | W whatever = &some_rts_var; /* will pick address not to a real | variable, but to a | so called | function stub, a separate structure | pointing to real | 'some_rts_var' */ | | I plan to tweak syntax to teach Cmm to distinct between | imported C global variables/constants, imported Cmm info | tables(closures), maybe other cases. | | I thought of adding haskell-like syntax for imports: | foreign ccall import some_rts_fun; | foreign cdata import some_rts_var; | | or maybe | import some_rts_fun; | import "&some_rts_fun" as some_rts_fun; | | This sort of bugs can be easily spotted by whole-program C compiler. | gcc can do it with -flto option. I basically added to the mk/build.mk: | SRC_CC_OPTS += -flto | SRC_LD_OPTS += -flto -fuse-linker-plugin | SRC_HC_OPTS += -optc-flto | SRC_HC_OPTS += -optl-flto -optl-fuse-linker-plugin | and started with './configure --enable-unregisterised' | | It immediately shown some of current offenders: | error: variable 'ghczmprim_GHCziTypes_False_closure' redeclared as | function | error: variable 'ghczmprim_GHCziTypes_True_closure' redeclared as | function | | I hope this fuzzy explanation makes some sense. | | Thanks! | | > Sergei | > | > C-- was originally envisaged as a target language for a variety of | compilers. But in fact LLVM, which was developed at a similar time, | "won" that race and has built a far larger ecosystem. That's fine with | us -- it's great how successful LLVM has been -- but it means that C-- is | now used essentially only in GHC. | > | > I'm not sure where the original C-- documents now are; Norman can you | say? (I do know that the cminusminus.org has lapsed.) | > | > The GHC variant of C-- is defined mainly by the Cmm data type in GHC's | source code. It does have a concrete syntax, because some bits of GHC's | runtime system are written in Cmm. But I fear that this concrete language | is not well documented. (Simon Marlow may know more here.) | > | > Because GHC's Cmm is part of GHC, we are free to change it. Would you | like to say more about the change you want to make, and why you want to | make it? Is this relating directly to GHC or to some other project? | > | > Simon | > | > | > | -----Original Message----- | > | From: Sergei Trofimovich [mailto:slyich@gmail.com] | > | Sent: 14 September 2014 17:16 | > | To: Simon Peyton Jones | > | Subject: cminusminus.org does not have a link to the spec | > | | > | Hello Simon! | > | | > | I had a plan to tweak a bit "import" statement | > | syntax of Cmm in GHC. | > | | > | Namely, to distinct between | > | import some_c_function; | > | import some_c_global_variable; | > | | > | To try it I first attempted to find latest c-- spec | > | (to find some design sketches if available) at | > | | > | http://www.cminusminus.org/c-downloads/ | > | | > | But seems the links (and images?) have gone away | > | as well as rsync server described at: | > | | > | http://www.cminusminus.org/the-c-rsync-server/ | > | | > | Maybe you could forward it to site admins so they would | > | tweak links or point me to working copy. | > | | > | Apologies for bothering you on such minor | > | | > | Thank you! | > | | > | -- | > | | > | Sergei | | | -- | | Sergei

Simon M: this is more your bailiwick than mine. Sergei: It's always a good idea to create a Trac ticket to accompany a Phab patch, because we have better milestone/priority support for Trac tickets. Don't forget to explain the motivation and rationale, giving examples. If it all gets too voluminous, start a Trac wiki page. Apols if you have done so already; I'm offline. Simon | -----Original Message----- | From: Sergei Trofimovich [mailto:slyich@gmail.com] | Sent: 17 January 2015 18:42 | To: Simon Peyton Jones | Cc: Norman Ramsey; ghc-devs; Simon Marlow | Subject: Re: cminusminus.org does not have a link to the spec | | On Tue, 16 Sep 2014 20:23:10 +0000 | Simon Peyton Jones wrote: | | > Thanks. This is beyond my competence, and I'm totally submerged | anyway. I suggest you make a Trac ticket about it anyway. Simon Marlow | will probably have an opinion. | | Today I've found an excuse to actually implement it :) | https://phabricator.haskell.org/D622 | | Reused 'CLOSURE' token and added | import CLOSURE id; | to existing | import id; | | > | -----Original Message----- | > | From: Sergei Trofimovich [mailto:slyich@gmail.com] | > | Sent: 16 September 2014 19:03 | > | To: Simon Peyton Jones | > | Cc: Norman Ramsey; ghc-devs; Simon Marlow | > | Subject: Re: cminusminus.org does not have a link to the spec | > | | > | On Mon, 15 Sep 2014 12:05:27 +0000 | > | Simon Peyton Jones wrote: | > | | > | My planned change is for GHC's .cmm files syntax/codegen. | > | The idea came out after having stumbled upon a rare ia64 | > | bug in GHC's C codegen: | > | | > | | > | | http://git.haskell.org/ghc.git/commitdiff/e18525fae273f4c1ad8d6cbe1dea4fc | > | 074cac721 | > | | > | The fundamental bug here is the following: | > | Suppose we have two bits of rts: one .c file and one .cmm file | > | | > | // rts.c defines and exports a function and a variable | > | void some_rts_fun (void); | > | int some_rts_var; | > | | > | // rts.cmm uses rts.c's function and variable | > | import some_rts_fun; /* this forces C codegen to emit function- | like | > | 'StgFunPtr some_rts_fun | ();' | > | prototype, it's fine */ | > | | > | import some_rts_var; /* also forces C codegen to emit function- | like | > | 'StgFunPtr some_rts_var | ();' | > | prototype, it's broken */ | > | // ... | > | W whatever = &some_rts_var; /* will pick address not to a real | > | variable, but to a | > | so called | > | function stub, a separate structure | > | pointing to | real | > | 'some_rts_var' */ | > | | > | I plan to tweak syntax to teach Cmm to distinct between | > | imported C global variables/constants, imported Cmm info | > | tables(closures), maybe other cases. | > | | > | I thought of adding haskell-like syntax for imports: | > | foreign ccall import some_rts_fun; | > | foreign cdata import some_rts_var; | > | | > | or maybe | > | import some_rts_fun; | > | import "&some_rts_fun" as some_rts_fun; | > | | > | This sort of bugs can be easily spotted by whole-program C compiler. | > | gcc can do it with -flto option. I basically added to the | mk/build.mk: | > | SRC_CC_OPTS += -flto | > | SRC_LD_OPTS += -flto -fuse-linker-plugin | > | SRC_HC_OPTS += -optc-flto | > | SRC_HC_OPTS += -optl-flto -optl-fuse-linker-plugin | > | and started with './configure --enable-unregisterised' | > | | > | It immediately shown some of current offenders: | > | error: variable 'ghczmprim_GHCziTypes_False_closure' redeclared | as | > | function | > | error: variable 'ghczmprim_GHCziTypes_True_closure' redeclared | as | > | function | > | | > | I hope this fuzzy explanation makes some sense. | > | | > | Thanks! | > | | > | > Sergei | > | > | > | > C-- was originally envisaged as a target language for a variety of | > | compilers. But in fact LLVM, which was developed at a similar time, | > | "won" that race and has built a far larger ecosystem. That's fine | with | > | us -- it's great how successful LLVM has been -- but it means that C- | - is | > | now used essentially only in GHC. | > | > | > | > I'm not sure where the original C-- documents now are; Norman can | you | > | say? (I do know that the cminusminus.org has lapsed.) | > | > | > | > The GHC variant of C-- is defined mainly by the Cmm data type in | GHC's | > | source code. It does have a concrete syntax, because some bits of | GHC's | > | runtime system are written in Cmm. But I fear that this concrete | language | > | is not well documented. (Simon Marlow may know more here.) | > | > | > | > Because GHC's Cmm is part of GHC, we are free to change it. Would | you | > | like to say more about the change you want to make, and why you want | to | > | make it? Is this relating directly to GHC or to some other project? | > | > | > | > Simon | > | > | > | > | > | > | -----Original Message----- | > | > | From: Sergei Trofimovich [mailto:slyich@gmail.com] | > | > | Sent: 14 September 2014 17:16 | > | > | To: Simon Peyton Jones | > | > | Subject: cminusminus.org does not have a link to the spec | > | > | | > | > | Hello Simon! | > | > | | > | > | I had a plan to tweak a bit "import" statement | > | > | syntax of Cmm in GHC. | > | > | | > | > | Namely, to distinct between | > | > | import some_c_function; | > | > | import some_c_global_variable; | > | > | | > | > | To try it I first attempted to find latest c-- spec | > | > | (to find some design sketches if available) at | > | > | | > | > | http://www.cminusminus.org/c-downloads/ | > | > | | > | > | But seems the links (and images?) have gone away | > | > | as well as rsync server described at: | > | > | | > | > | http://www.cminusminus.org/the-c-rsync-server/ | > | > | | > | > | Maybe you could forward it to site admins so they would | > | > | tweak links or point me to working copy. | > | > | | > | > | Apologies for bothering you on such minor | > | > | | > | > | Thank you! | | -- | | Sergei