asm-js

validator

JavaScript2013–2015

asm-js / validator

validator

A reference validator for asm.js.

Learning & Reference

Explore on GitHub Read Hacker News discussions

5Distinct people

8Mentions

0Explicit recommenders

1.8KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A reference validator for asm.js.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month8 dated mentions

Observed mentions: 2013-01-05 14:58:36 UTC to 2015-02-18 23:18:18 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Jan 2013	2013-01-01 00:00:00 UTC	2013-02-01 00:00:00 UTC	1	1
Feb 2013	2013-02-01 00:00:00 UTC	2013-03-01 00:00:00 UTC	2	2
Mar 2013	2013-03-01 00:00:00 UTC	2013-04-01 00:00:00 UTC	1	1
Apr 2013	2013-04-01 00:00:00 UTC	2013-05-01 00:00:00 UTC	0	0
May 2013	2013-05-01 00:00:00 UTC	2013-06-01 00:00:00 UTC	1	1
Jun 2013	2013-06-01 00:00:00 UTC	2013-07-01 00:00:00 UTC	1	1
Jul 2013	2013-07-01 00:00:00 UTC	2013-08-01 00:00:00 UTC	0	0
Aug 2013	2013-08-01 00:00:00 UTC	2013-09-01 00:00:00 UTC	0	0
Sep 2013	2013-09-01 00:00:00 UTC	2013-10-01 00:00:00 UTC	0	0
Oct 2013	2013-10-01 00:00:00 UTC	2013-11-01 00:00:00 UTC	0	0
Nov 2013	2013-11-01 00:00:00 UTC	2013-12-01 00:00:00 UTC	0	0
Dec 2013	2013-12-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	0	0
Jan 2014	2014-01-01 00:00:00 UTC	2014-02-01 00:00:00 UTC	0	0
Feb 2014	2014-02-01 00:00:00 UTC	2014-03-01 00:00:00 UTC	0	0
Mar 2014	2014-03-01 00:00:00 UTC	2014-04-01 00:00:00 UTC	0	0
Apr 2014	2014-04-01 00:00:00 UTC	2014-05-01 00:00:00 UTC	0	0
May 2014	2014-05-01 00:00:00 UTC	2014-06-01 00:00:00 UTC	0	0
Jun 2014	2014-06-01 00:00:00 UTC	2014-07-01 00:00:00 UTC	0	0
Jul 2014	2014-07-01 00:00:00 UTC	2014-08-01 00:00:00 UTC	0	0
Aug 2014	2014-08-01 00:00:00 UTC	2014-09-01 00:00:00 UTC	0	0
Sep 2014	2014-09-01 00:00:00 UTC	2014-10-01 00:00:00 UTC	0	0
Oct 2014	2014-10-01 00:00:00 UTC	2014-11-01 00:00:00 UTC	0	0
Nov 2014	2014-11-01 00:00:00 UTC	2014-12-01 00:00:00 UTC	0	0
Dec 2014	2014-12-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	0	0
Jan 2015	2015-01-01 00:00:00 UTC	2015-02-01 00:00:00 UTC	1	1
Feb 2015	2015-02-01 00:00:00 UTC	2015-03-01 00:00:00 UTC	1	1

What Hacker News says

8 sources

azakai·Feb 18, 2015

Yeah, ffis are just calls like any other, with the usual annotations and types on parameters and return values, etc. They just happen to be to functions on the outside of the asm module. edit: btw, there is a full example here https://github.com/dherman/asm.js/#example

In What does “asm.js optimizations” mean?

azakai·Jan 30, 2015

Of course I agree that the chromium project itself, as opposed to the chromium browser, is developed openly and in a nice way. There is no argument between us on that - it's a clear fact. And I agree that in a large project like a browser, compromises can be necessary when you must work with partners, as in the examples that you made. Good points. But I strongly disagree on two things you mention: Regarding asm.js, that is not how it was developed. It was from day 1 done on an open github repo, https://github.com/dherman/asm.js/ There was never anything secret about it. (What would we have even gained by being secretive about it? Nothing.) Also, in v8 the issue is not just CrankShaft and TurboFan, but as I mentioned, daily development. I file bugs when I find v8 failing on an emscripten output, and so I follow v8 commits. There is almost

Read the rest

no public discussion on them - just patches, plus perhaps a review comment or two. No public bug with background, explanations, motivation, etc. The code is open, but development is clearly not. I think it's obvious v8 is a major part of chromium, and it's completely unnecessarily developed in a non-open manner. So I think it's fair to say the chromium browser as a whole - as opposed to the chromium project itself - is not developed fully openly. Another example is Dart. Dart is not yet part of chromium, but the plans to integrate it are public. Dart was developed secretly for a while, and in fact only became known unintentionally in a leaked email. It's not clear when it would have become public if not for that leaked email. Again, like with v8, this is unnecessarily closed development - there are no legal issues or partners that must be compromised with. It was just decided that v8 and Dart would be developed non-openly (for reasons I can't understand).

In Firefox Hello

niutech·Jun 28, 2013

Here is a community list of projects using asm.js: https://github.com/dherman/asm.js/wiki/Projects-using-asm.js

In What asm.js is and isn't

pcwalton·May 18, 2013

https://github.com/dherman/asm.js/tree/master/lib is about 1,500 lines of code. The contents of Bitcode/Reader/ in LLVM are about 3,000 lines of code alone, and that does not include the definition of LLVM data structures, the validator, etc.

In Google Introduces Portable Native Client

azakai·Mar 28, 2013

> Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, I don't think that's accurate. We started work on asm.js only a few months ago; at the beginning, we had no idea if it would work, so we just threw around some ideas between each other. When we had something we felt could actually work, we immediately put it up on https://github.com/dherman/asm.js And worked on it there. asm.js has been discussed on IRC (#emscripten and other places), the emscripten mailing list, etc., as we further improved the spec. About the middle last month, we got some performance numbers, and felt we could say something about speed, so I mentioned asm.js in my talk at mloc.js and other more noticeable places, but it was definitely not a secret far before th

Read the rest

at. > relies extensively on engine quirks That would be a bad bug in the asm.js spec. Can you please elaborate?

In "Optimizations should be added to V8" for the asm.js subset of JavaScript

pcwalton·Feb 19, 2013

"Why not just define a bytecode spec and be done with all of this nonsense?" Because such bytecode would not be backwards compatible. "Defining a simple register or stack based machine and producing bytecode for it would greatly simplify the job of implementers" Let's take as a given that every browser that wants to implement asm.js needs a JavaScript parser (for JS content on the Web) and an asm.js compiler IR. The question, then, is whether it's simpler to write a verifier that simply walks over parse trees or whether it's simpler to write a reader for whatever custom bytecode is defined. I don't think that the verifier is much harder: the JS version of the verifier clocks in at just over 1,000 lines of code [1], which is nothing compared to the size of the VM as a whole. Certainly that 1,000 lines of code doesn't justify breaking backw

Read the rest

ards compatibility, in my mind. "it would make defining the specification and determining compliance with the standard very straight forward" The specification already more or less exists, and determining compliance is straightforward: 1,000 lines of code for the reference implementation. "it would let us eventually do web programming without being tied to a specific language" asm.js doesn't tie you to a language. On the contrary, it allows you to use alternative languages in order to get better performance than you would if you used normal JavaScript. JS is used as the transport format for backwards compatibility, nothing more. In fact, in SpiderMonkey, asm.js has its own set of IR opcodes (Asm*) that are separate from the JavaScript opcodes. [1]: https://github.com/dherman/asm.js

In Asm.js: A Low Level, Highly Optimizable Subset of JavaScript for Compilers

evincarofautumn·Feb 16, 2013

Looks like it’s in the works. https://github.com/dherman/asm.js/issues/4

In Asm.js: a strict subset of js for compilers – working draft

Benvie·Jan 5, 2013

I had considered this, but it would also require the other end of it. RPython is basically compiled to C which is compiled to machine code. The ultimate output format for this needs to be JavaScript, something like the form specified by https://github.com/dherman/asm.js. So we need JavaScript (ES6) coming in one end and asm.js coming out the other end. At this point the only remaining usable pieces from PyPy are the processing that happens in the middle. Admittedly this is a huge part of it and would still be very valuable to have access to, but there's probably a better approach to this than having to redo both ends of the pipeline, and losing the ability to self-host the compilation process in a JavaScript engine (browser). Perhaps pairing PyPy with emscripten would be the ideal solution for this, but that would have to be a completely

Read the rest

new project because nothing that's currently in Continuum would be useful for that (except probably the standard library that's written in ES6 and executed in the VM).

In Continuum - A javascript ES6 VM