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
