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.

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.

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.

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.

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***);

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

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

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

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

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.