[GHC] #7933: JavaScript Cmm backend

[GHC]

#7933: JavaScript Cmm backend
---------------------------------+------------------------------------------
    Reporter:  bosu              |       Owner:  bosu            
        Type:  feature request   |      Status:  patch           
    Priority:  normal            |   Milestone:                  
   Component:  Compiler          |     Version:  7.6.3           
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------
Changes (by bosu):

  * owner:  => bosu


Comment:

 Replying to [comment:3 simonpj]:

 >
 >  You aren't the first to attack this problem; see
 [http://www.haskell.org/haskellwiki/The_JavaScript_Problem the Haskell
 wiki JS page].

 Yes, I am aware of this page. I am going to update it.

 > How does your solution differ?

 Here is short recap, AFAIK:

 * Fay does not use GHC code generation, therefore there is no relation at
 all.

 * Both Haste and GHCJS skip Cmm step, generating JS from STG.

 * Haste and GHCJS are standalone compilers using GHC APIs.

 > I'd love to see comments from Fay's author, GHCJS's author etc.
 > Maybe you can make common cause with some of them to get JS into GHC?

 I definately will, once more tests are passing :)

 >
 >  More generally, before adopting it for GHC, I'd ideally like to see a
 group
 > of enthusiasts saying "yes, this is the way to go".  I'm not well
 equipped to
 > make a critical assessment from a JS point of view.
 >

 I understand and will do.

 >  You could start a GHC Trac Wiki page describing the implementation in
 overview,
 > so someone could figure out how it works (eg including some of the
 description above).

 Yes, I'll do this.

 >
 >  Also the code needs comments!  At the moment the code has various
 places saying
 >`if hscTarget dflags == HscJavaScript`, but no comment explaining why
 that special case
 > is important at that point. I comment the the `Note [blah]` format; see
 [http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle coding
 style].
 > I can see why you have not invested in comments so far; fair enough, but
 in the
 > end they'll be necessary.

 Sure, I'll add comments and Note's.

 >
 >  Similarly, at a larger scale, I have no clue how `PointerMarker` works
 or what it
 >  is doing.

 It tries to distinguish between pointers and int values.

 Suppose that p is a GC pointer. Native GHC backend can regard (p + 4) as a
 regular
 int value.

 However on the JS backend, p is allocated as JS object (closure). p + 4 is
 meaningless there.
 Therefore I convert p + 4 as p(OP_ADD, 4).

 `PointerMarker` tries to deduce whether register is a pointer by finding
 loads and stores
 using it.

 Unfortunately, there are some corner cases where these heuristics do not
 work. In that
 case we have to fallback to the runtime checks.

 Eventually, I'd like to solve this problem by having separate `CmmType`
 category for pointers.

 >
 > Finally, who are you in real life, bosu?  As you going to do this and
 move on,
 > or would you plan to actively support/develop this JS back end?  (We had
 a Java back
 > end whose author moved on, and it was a pain. Eventually we deleted it
 again.)
 >

 I'm just a programmer doing this as a hobby. GHC is wonderful, I'd like to
 stick around :).

 Thanks,

 Boris.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7933#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler