RE: cminusminus.org does not have a link to the spec
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:sly...@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 + | Simon Peyton Jones simo...@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:sly...@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 + | | 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/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
Re: cminusminus.org does not have a link to the spec
Hi Sergei, See http://www.cs.tufts.edu/~nr/c--/extern/man2.ps Google is your friend! Howard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cminusminus.org does not have a link to the spec
On Tue, 16 Sep 2014 20:23:10 + Simon Peyton Jones simo...@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:sly...@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 + | 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/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: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. |
Re: cminusminus.org does not have a link to the spec
On Mon, 15 Sep 2014 12:05:27 + 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
RE: cminusminus.org does not have a link to the spec
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. Simon | -Original Message- | From: Sergei Trofimovich [mailto:sly...@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 + | 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/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: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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: cminusminus.org does not have a link to the spec
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cminusminus.org does not have a link to the spec
the historical c-- page still lives where norman moved it www.cs.tufts.edu/~nr/c--/index.html (and has all the content still) On Mon, Sep 15, 2014 at 8:05 AM, Simon Peyton Jones simo...@microsoft.com wrote: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
