cminusminus.org does not have a link to the spec

Sergei Trofimovich slyich at gmail.com
Sat Jan 17 18:42:27 UTC 2015


On Tue, 16 Sep 2014 20:23:10 +0000
Simon Peyton Jones <simonpj at microsoft.com> 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 at 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 <simonpj at 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/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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150117/8932d9be/attachment-0001.sig>


More information about the ghc-devs mailing list