Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NanoJIT to WASM comparison - a compelling argument? #100

Open
grubermeister opened this issue Nov 6, 2017 · 2 comments
Open

NanoJIT to WASM comparison - a compelling argument? #100

grubermeister opened this issue Nov 6, 2017 · 2 comments

Comments

@grubermeister
Copy link

While I understand and agree with this project's perspective of keeping Flash/Shockwave alive by preserving it in the open, for historical/archival purposes, I believe there could also be some compelling technical reasons for wanting this technology. Admittedly, I've only been investigating this fairly recently, but in my efforts, this article cropped up:

http://www.masonchang.com/blog/2010/11/10/tamarin-on-llvm.html

In here, the author performs a series of benchmarks comparing an LLVM backend of an existing open-source Flash implementation, Tamarin, to the NanoJIT implementation of the Actionscript ByteCode (ABC) backend. The results are quite interesting, with many cases of the NanoJIT actually managing to pull ahead in some regards!

The Flash technologies were engineered from the ground-up to provide a small-footprint, fast-interpreted multimedia technology for the web. These goals are clearly aligned with those of the WebAssembly project in attempting to foster a universal bytecode. I believe a proper comparison of WASM and ABC is in order, as perhaps there are some areas where Adobe has gathered implementation knowledge in overcoming certain obstacles that the WebAssembly team has not yet considered.

This, to me, forms one of the most compelling reasons to open Flash as much as possible - specifically any patents still pertaining to technologies such as the NanoJIT. If ABC could stand as the complete bytecode implementation to be integrated in the same space as WASM, with some technology such as Mozilla's Shumway making a comeback to convert the remaining elements in an SWF file to HTML5/CSS3 objects, plugin-less full-browser integration of Flash could become a real possibility. Archival teams would then merely have to work to convert older-format files to the latest versions, so the attack surface, and undefined behavior for such an implementation would not be anywhere near as great as current implementations of the Player.

What are your guys' thoughts? I'm honestly really excited to dive in and take a look at all of this!

@pakastin
Copy link
Collaborator

pakastin commented Jan 4, 2018

Interested in making pull request about this..?

@ROBERT-MCDOWELL
Copy link
Contributor

great comment gubermesiter, just go ahead, we are running on time now.... everyone is trying to organize a battle counter attack....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants