www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Generating Javascript or asm.js from LDC?

reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
Hi.

Adam Ruppe made a comment on a thread in main room suggesting it 
might already be possible to generate JS or asm.js from LDC if 
compiled with the right options (and for LLVM too).

Is this by any chance possible?

If it's not possible today, how much work is involved?


Thanks.


Laeeth.
Sep 04 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 4 September 2015 at 18:47:06 UTC, Laeeth Isharc wrote:

 Is this by any chance possible?


I'm not entirely sure myself, but my theory is if you can feed 
the llvm code out of ldc and into the emscripten backend... the 
basics should just work, D can pretend to be C, and we build up 
from there. Indeed, the whole D runtime might even build - if 
we're really lucky - since some Linux functions are apparently 
supported by emscripten.

But I haven't actually tried doing it.
Sep 04 2015
next sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Saturday, 5 September 2015 at 01:32:43 UTC, Adam D. Ruppe 
wrote:

 On Friday, 4 September 2015 at 18:47:06 UTC, Laeeth Isharc 
 wrote:

 Is this by any chance possible?


 I'm not entirely sure myself, but my theory is if you can feed 
 the llvm code out of ldc and into the emscripten backend... the 
 basics should just work, D can pretend to be C, and we build up 
 from there. Indeed, the whole D runtime might even build - if 
 we're really lucky - since some Linux functions are apparently 
 supported by emscripten.

 But I haven't actually tried doing it.


I'd love to try, and will if/when I get the time.

There's value to me in being able to have a single codebase 
because I am less interested in doing anything that looks superb 
from a presentation point of view and more interested in web as 
one platform for some simple tools I have been working on.
Sep 05 2015
parent "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Saturday, 5 September 2015 at 12:51:20 UTC, Laeeth Isharc 
wrote:

 On Saturday, 5 September 2015 at 01:32:43 UTC, Adam D. Ruppe 
 wrote:

 On Friday, 4 September 2015 at 18:47:06 UTC, Laeeth Isharc 
 wrote:

 Is this by any chance possible?


 I'm not entirely sure myself, but my theory is if you can feed 
 the llvm code out of ldc and into the emscripten backend... 
 the basics should just work, D can pretend to be C, and we 
 build up from there. Indeed, the whole D runtime might even 
 build - if we're really lucky - since some Linux functions are 
 apparently supported by emscripten.

 But I haven't actually tried doing it.


 I'd love to try, and will if/when I get the time.

 There's value to me in being able to have a single codebase 
 because I am less interested in doing anything that looks 
 superb from a presentation point of view and more interested in 
 web as one platform for some simple tools I have been working 
 on.


for example I have a charting application.  at the moment I just 
use MathGL (no relation to OpenGL) to generate a static PNG.  I'd 
like to turn that into something interactive.  will need a native 
client, but a web one as a backup.  so would be great to have a 
single codebase.
Sep 05 2015
prev sibling next sibling parent "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Saturday, 5 September 2015 at 01:32:43 UTC, Adam D. Ruppe 
wrote:

 On Friday, 4 September 2015 at 18:47:06 UTC, Laeeth Isharc 
 wrote:

 Is this by any chance possible?


 I'm not entirely sure myself, but my theory is if you can feed 
 the llvm code out of ldc and into the emscripten backend... the 
 basics should just work, D can pretend to be C, and we build up 
 from there. Indeed, the whole D runtime might even build - if 
 we're really lucky - since some Linux functions are apparently 
 supported by emscripten.

 But I haven't actually tried doing it.



http://wiki.dlang.org/GSOC_2013_Ideas

Develop a simple way to compile D for the browser with Emscripten 
to "asm.js" (***this is a very small project***);
Sep 05 2015
prev sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
On Saturday, 5 September 2015 at 01:32:43 UTC, Adam D. Ruppe 
wrote:

 On Friday, 4 September 2015 at 18:47:06 UTC, Laeeth Isharc 
 wrote:

 Is this by any chance possible?


 I'm not entirely sure myself, but my theory is if you can feed 
 the llvm code out of ldc and into the emscripten backend... the 
 basics should just work, D can pretend to be C, and we build up 
 from there. Indeed, the whole D runtime might even build - if 
 we're really lucky - since some Linux functions are apparently 
 supported by emscripten.

 But I haven't actually tried doing it.


Fwiw I tried it, not really expecting much.  It didn't work, and 
I'm not sufficiently familiar with clang and llvm to understand 
the meaning of the errors.

import core.stdc.stdio;

void main()
{
	printf("hello");
}

ldc -O0 test2.d --output-bc
emcc test2.bc -O0 -v

INFO     root: (Emscripten: Running sanity checks)
WARNING: Linking two modules of different data layouts: 
'/home/laeeth/.emscripten_cache/libc.bc' is 
'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'llvm-link' is 
'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

WARNING: Linking two modules of different target triples: 
/home/laeeth/.emscripten_cache/libc.bc' is 
'asmjs-unknown-emscripten' whereas 'llvm-link' is 
'x86_64-unknown-linux-gnu'

WARNING: Linking two modules of different data layouts: 
'/home/laeeth/.emscripten_cache/dlmalloc.bc' is 
'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'llvm-link' is 
'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

WARNING: Linking two modules of different target triples: 
/home/laeeth/.emscripten_cache/dlmalloc.bc' is 
'asmjs-unknown-emscripten' whereas 'llvm-link' is 
'x86_64-unknown-linux-gnu'

PAL[
   { 1 => byval }
   { ~0U => uwtable }
]
LLVM ERROR: Attribute should already have been removed by 
ExpandByVal
Traceback (most recent call last):
   File "/usr/lib/emscripten/emcc", line 1271, in <module>
     shared.Building.llvm_opt(final, link_opts)
   File "/usr/lib/emscripten/tools/shared.py", line 1412, in 
llvm_opt
     assert os.path.exists(target), 'Failed to run llvm 
optimizations: ' + output
AssertionError: Failed to run llvm optimizations:


====
I don't know, but looks like they modified clang too:
https://github.com/Laeeth/emscripten-fastcomp-clang

some colour here:
https://kripken.github.io/emscripten-site/docs/contributing/developers_guide.html#developer-s-guide
Sep 05 2015
next sibling parent reply "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
I guess you would need to implement within LDC js architecture 
and emscripten OS, so perhaps it's not quite so straightforward...
Sep 05 2015
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 5 Sep 2015, at 17:29, Laeeth Isharc via digitalmars-d-ldc wrote:

 I guess you would need to implement within LDC js architecture and 
 emscripten OS, so perhaps it's not quite so straightforward...


Just looked at the developer docs you linked, and it seems like they 
indeed have a custom LLVM fork. The easiest thing to do would probably 
be to compile LDC against that fork (just point the LLVM_CONFIG CMake 
variable at their llvm-config binary). Apart from that, not much should 
be needed per se (apart from adding it as a recognized OS in a couple of 
places that might report an error otherwise, e.g. in the code that sets 
the linux/Windows/Darwin/... version definitions).

  — David
Sep 05 2015
next sibling parent "Laeeth Isharc" <spamnolaeeth nospamlaeeth.com> writes:
On Saturday, 5 September 2015 at 15:23:18 UTC, David Nadlinger 
wrote:

 On 5 Sep 2015, at 17:29, Laeeth Isharc via digitalmars-d-ldc 
 wrote:

 I guess you would need to implement within LDC js architecture 
 and emscripten OS, so perhaps it's not quite so 
 straightforward...


 Just looked at the developer docs you linked, and it seems like 
 they indeed have a custom LLVM fork. The easiest thing to do 
 would probably be to compile LDC against that fork (just point 
 the LLVM_CONFIG CMake variable at their llvm-config binary). 
 Apart from that, not much should be needed per se (apart from 
 adding it as a recognized OS in a couple of places that might 
 report an error otherwise, e.g. in the code that sets the 
 linux/Windows/Darwin/... version definitions).

  — David


Very cool if this is the case.  I don't really know my way around 
LLVM, let alone LDC or emscripten.  I'll have a try.  But even if 
its beyond what I can do for now, the payoff seems pretty good if 
it turns out to be not so much work.
Sep 05 2015
prev sibling parent "Laeeth Isharc" <spamnolaeeth nospamlaeeth.com> writes:
On Saturday, 5 September 2015 at 15:23:18 UTC, David Nadlinger 
wrote:

 On 5 Sep 2015, at 17:29, Laeeth Isharc via digitalmars-d-ldc 
 wrote:

 I guess you would need to implement within LDC js architecture 
 and emscripten OS, so perhaps it's not quite so 
 straightforward...


 Just looked at the developer docs you linked, and it seems like 
 they indeed have a custom LLVM fork. The easiest thing to do 
 would probably be to compile LDC against that fork (just point 
 the LLVM_CONFIG CMake variable at their llvm-config binary). 
 Apart from that, not much should be needed per se (apart from 
 adding it as a recognized OS in a couple of places that might 
 report an error otherwise, e.g. in the code that sets the 
 linux/Windows/Darwin/... version definitions).

  — David


The thing is they also have a custom clang fork, and I wonder 
what changes need to be made to the front end (LDC in this case) 
to fit.
Sep 05 2015
prev sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Laeeth,

On 5 Sep 2015, at 17:15, Laeeth Isharc via digitalmars-d-ldc wrote:

 Fwiw I tried it, not really expecting much.  It didn't work, and I'm 
 not sufficiently familiar with clang and llvm to understand the 
 meaning of the errors.



 WARNING: Linking two modules of different data layouts: 
 '/home/laeeth/.emscripten_cache/libc.bc' is 
 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'llvm-link' is 
 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'


Seems like Emscripten uses 32 bit pointers whereas you compiled the D 
sources for a 64 bit target.


 WARNING: Linking two modules of different target triples: 
 /home/laeeth/.emscripten_cache/libc.bc' is 'asmjs-unknown-emscripten' 
 whereas 'llvm-link' is 'x86_64-unknown-linux-gnu'


You could easily make LDC emit a different target triple. I'm not sure 
whether asmjs/emscripted are recognized by LLVM by default, but if so, 
it's as simple as using the -mtriple argument or hacking the code in 
ldc/driver/targetmachine.cpp (just search for "triple"). If not, there 
is probably an Emscripten patch to LLVM that adds support.



 PAL[
 { 1 => byval }
 { ~0U => uwtable }
 ]
 LLVM ERROR: Attribute should already have been removed by ExpandByVal
 Traceback (most recent call last):
 File "/usr/lib/emscripten/emcc", line 1271, in <module>
  shared.Building.llvm_opt(final, link_opts)
 File "/usr/lib/emscripten/tools/shared.py", line 1412, in llvm_opt
  assert os.path.exists(target), 'Failed to run llvm optimizations: ' + 
 output


Looks like emscripten either expects frontends not to generate "byval" 
parameters, or there is some kind of previous pass you are supposed to 
run (probably "ExpandByVal", from the error message) to lower them.

— David
Sep 05 2015