Direct-to-asm.js backend

[pipcet]

Currently works with the SpiderMonkey shell. Shouldn't be hard to port to browsers or node.js.

[larsbrinkhoff]

I lifted a whitespace fix off your branch. This resulted in a merge conflict, so I rebased and force-pushed your branch.

Your changes breaks the other targets, so there's still some work to do.

[pipcet]

I think I've mostly fixed the conditional compilation code; what doesn't work yet is to compile a non-asm.js target with the asm.js backend. Still investigating that one.

[larsbrinkhoff]

I added a commit with a run.sh script.

[larsbrinkhoff]

I tried to actually run this. I installed "libmozjs-24-bin" which provides a binary called "js24". This doesn't work though:

h$ js24 forth.js
warning: successfully compiled asm.js code (total compilation time 1ms)
forth.js:3:0 Error: unknown option name 'throw_on_asmjs_validation_failure'. The valid names are strict, typeinfer, werror and strict_mode.

If I comment out the options() line in forth.js, I get

forth.js:97:0 ReferenceError: os is not defined

[pipcet]

Yes, the js shell's API has changed, unfortunately. The nightly-build JS shell is at https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/jsshell-linux-x86_64.zip, and should work. I can look into backporting to the old shells.

[pipcet]

I've pushed a patch that works with the version of js24 I have here, at least. I don't know whether node.js still has synchronous functions to simply read a line of stdin input; otherwise, porting might be a bit difficult.

[larsbrinkhoff]

Thanks! It runs now.

I noticed that the dumping code doesn't seem to work with a 64-bit bootstrap Forth. The contents of forth.js doesn't look right.

[larsbrinkhoff]

I'm trying to run the tests, as in make check. But the first test case fails not finding the file test/hayes/runtests.fth.

Do all host files used inside Forth need to be included in the load_files function?

[pipcet]

At present, yes, it only finds the files it's built with. I was going to fix that...

Thanks for testing, by the way! Obviously I hadn't figured out how to run the tests...

And, yes, the dumping code assumed 32 bits. Hopefully fixed in a minute.

[larsbrinkhoff]

I see you have a bootstrap.mk. Do you still need that for anything? It refers to a forth2asmjs.fs which doesn't seem to be present.

In the master branch, boostrapping can only be done with the Lisp metacompiler and the C target. Of course it would be possible to bootstrap with the asmjs target too, but it would add some complexity.

[pipcet]

okay, hopefully that fixes the file issue, and bootstrap.mk has been deleted. I'm seeing one asm test failure for x86 now.

[larsbrinkhoff]

Can you run e.g. ./asmjs-forth < test/test-input?

Or even simpler maybe, create a file t.fth with .( hello ). Then start Forth and type include t.fth. This still says "File not found" here.

[pipcet]

Weird, it works here, even after a git reset --hard, for both js24 and the nightly shell...

[pipcet]

Ah, the x86 assembler assumes unaligned access works (in >mark4, specifically), and it doesn't on asm.js.

[larsbrinkhoff]

Ah, now it works. It could be that forth.js isn't removed by make clean.

[larsbrinkhoff]

The other targets build a file called \-forth. This file is a target-specific binary. To run this binary, there is a script called targets/\/run.sh.

Would it break anything if the asm.js target did the same? I.e. remove the forth.js file and put everything in asmjs-forth.

[larsbrinkhoff]

About >mark4, I believe it should use the ! from cross.fth which doesn't require aligned accesses.

If indeed the x86 cross assembler doesn't work, that's a bug.

[larsbrinkhoff]

I was wrong, the x86 assembler indeed uses the standard !. I'll fix that.

[larsbrinkhoff]

Why does foreign_bye print a timestamp? It adds to the output of Forth applications.

[larsbrinkhoff]

I added some more changes to build and test this with Travis CI, in both Linux and macOS.

[larsbrinkhoff]

It still fails in macOS. I don't know why.

[pipcet]

E: Unable to locate package libmozjs-24-bin

Is what the shippable build says. The Travis build tries to run a JavaScript file as though it were an executable, I think, and that fails.

[larsbrinkhoff]

Right, Shippable breaks because it's using Ubuntu 12. I updated Travis to Ubuntu 14, which has the libmozjs package.

The target Forth is always executed with the run.sh script, which takes care of finding the right interpreter if necessary.

The Travis build works fine in Linux, but macOS fails. I think it's not finding any js or js24 binary. Not sure under which name Homebrew installs the SpiderMonkey shell.

[larsbrinkhoff]

I see Meta-OK is only used in the C target. It's not needed in the asm.js target.

[pipcet]

You're quite right, I'd missed that the Meta-OK check went away. Hooray simplification!

[larsbrinkhoff]

I think this is good shape now.

Here's the plan:

• Fix macOS build, or remove it from Travis.
• Await finishing touches by you, if any.
• Rebase on top of current master, and squash into a single commit.
• Merge.

[pipcet]

Excellent! Thanks for all your work!

I suspect the MacOS build has "js" in the path, referring to node.js, before the SpiderMonkey shell, so it's probably easiest to simply support nodeJS...

[larsbrinkhoff]

In that case, I suggest stop trying to use SpiderMonkey on the Mac. And use nodejs in the future, if there is a port.

[pipcet]

Sounds good to me.

[larsbrinkhoff]

I did the rebasing and squashing. Anything you want to change?

[pipcet]

The one thing that still sticks out is the hardcoding of load addresses, particularly the 1024 in cold.fth. Other than that, I'm very happy with your improvements! Thanks again!

[larsbrinkhoff]

Thank you too!