On Mon, 15 Sep 2014 12:05:27 +0000 Simon Peyton Jones <simonpj@microsoft.com> 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/e18525fae273f4c1ad8d6cbe1dea4fc074... 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