#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
`if hscTarget dflags == HscJavaScript`, but no comment explaining why
is important at that point. I comment the the `Note [blah]` format; see [http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle coding
places saying that special case 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