Any chance of recompiling to http://asmjs.org/

[graingert]

You might even get quite close to native speed then!

[jterrace]

Yes, some other people are working on trying to update js.js to the latest version of Emscripten and LLVM.

[graingert]

Do you have a link to this?

[jterrace]

No, but I have notified the two people who are working on it with this issue. I will ask them to post here.

[steelejoe]

I am working on this now -- will post details when I get a bit closer.

[jterrace]

If you have any in-progress commits, feel free to push them to a branch. I can help you with any blockers.

[steelejoe]

Quick status update: I was able to spend a little time today. I updated build.py and conf.py to use the LLVM 3.2 and the current emscripten. Luckily I am only seeing two compile errors (lots of warnings though).

The errors are:
/home/steele/dev/latest/js.js/builder/build/mozilla-central/js/src/jsapi.cpp:355:18: error: no matching function for call to 'TryArgumentFormatter'
if (!TryArgumentFormatter(cx, &format, JS_TRUE, &sp,
^~~~~~~~~~~~~~~~~~~~
/home/steele/dev/latest/js.js/builder/build/mozilla-central/js/src/jsapi.cpp:225:1: note: candidate function not viable: no known conversion from 'int **' to 'va_list *' (aka '__builtin_va_list *') for 5th argument

In file included from /home/steele/dev/latest/js.js/builder/build/mozilla-central/js/src/jscompartment.cpp:53:
./assembler/jit/ExecutableAllocator.h:440:6: error: "The cacheFlush support is missing on this platform."
#error "The cacheFlush support is missing on this platform."
^

I am looking at the second error now, but I don't have much time tonight.

[jterrace]

The second error looks troubling because I thought we hacked the entire JIT assembler out of the code that gets compiled.

The first error is really confusing. Not sure where it's getting the int ** from, but maybe it's the wrong value for HAVE_VA_LIST_AS_ARRAY.

I can try and help you dig deeper when I get some time, let me know if you make any progress in the meantime.

[jterrace]

Do you have the updates in a branch somewhere I can check out?

[steelejoe]

I think I was able to get around both of these issues. I have the "fixes" in a local branch. I have not used github before to host my changes, I suppose I can put them up here? I will figure it out and put the info here.

[steelejoe]

Ok, I believe I successfully forked your repo and committed my changes here: https://github.com/steelejoe/js.js.git
I am a git newbie though so if you don't see any differences, I probably borked the commit. Please let me know and my apologies in advance. :)

I was able to get the compile to finish, I have not tested the output yet. The fix for the first error was pretty trivial the fix for the second seems hacky in the extreme. I realized after I committed that there are two changes that went into getting the compile to work and I am not sure which one did the trick (or if it was both). What is checked in is the hacky cast. What is not checked in is the setting of EMCC_LLVM_TARGET=i386-pc-linux-gnu which was suggested by the last question in the emscripten FAQ (https://github.com/kripken/emscripten/wiki/FAQ). I am trying again without the environment setting so I should know in a bit.

[steelejoe]

Looks like the hacky code is not needed. The EMCC_LLVM_TARGET setting does the trick although I am not sure of the performance implication for JS.

[jterrace]

I see your fork, but there are no new commits in there. Did you commit locally but forget to push?

[steelejoe]

You are right. I think it is in now.

[SunilAgrawal]

Hi, any update on this? Is the recompiled Js.js work any better, atleast on Firefox?

[jterrace]

Compiling now, but it takes a while.. I'll report back when I get a chance to try it out after it finishes.