cminusminus.org does not have a link to the spec

[Simon Peyton Jones]

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 at 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 <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