On Mon, 15 Sep 2014 12:05:27 +0000 Simon Peyton Jones <simo...@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/e18525fae273f4c1ad8d6cbe1dea4fc074cac721 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:sly...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs