Skip to main content

Posts

WebAssembly Comes to Hermes

WebAssembly Comes to Hermes Hermes can now compile and run WebAssembly modules. A standard .wasm binary - the same one that runs in a browser or Node.js - can be loaded into Hermes at runtime, or compiled ahead of time into Hermes bytecode ( .hbc ) for zero startup cost. The result is the same fast, compact bytecode format that Hermes already uses for JavaScript, executed by the same interpreter. Why does this matter? WebAssembly opens the door to reusing existing C, C++, and Rust libraries without writing native modules. Image processing, physics engines, crypto routines - anything compiled to Wasm can now run directly in the JS engine, using the standard WebAssembly API familiar from the browser. This post walks through the full pipeline - from C source code to running Wasm inside Hermes - and looks at what happens under the hood. The Simplest Example Let’s start with a function so small there’s nowhere to hide: computing the average of two integers. The C Source int avg ( ...
Recent posts

How to speed up a micro-benchmark 300x

How to speed up a ubenchmark 300x Static Hermes: How to Speed Up a Micro-benchmark by 300x Without Cheating This is the first of a series of light blog posts about Static Hermes, covering topics that I find interesting or amusing. It is not intended to be a systematic introduction to Static Hermes design.Consider it more like a backstage pass to the quirks, features, and “aha!” moments that make Static Hermes unique. If you’re not familiar with Static Hermes, it’s an evolving project we’re working on to explore the confluence of static typing and JavaScript. It is work in progress, but we’re excited about the possibilities it opens up for performance improvements and more. For more background: Tweet with the slide deck of the Static Hermes announcement Previous talk about Hermes Contents: Meet interp-dispatch.js Let’s Run It! Static Hermes with Untyped Code Helping the Compiler Other Ways to Help the Compiler Some Observations Revisiting The Origina...

Apple2TC: an Apple II Binary to C Decompiler - Part 7, Using The IR

 This is part 7 in a series of posts describing Apple2TC.  The start is in  Part 1 . Part 6 introduced our SSA-based Intermediate Representation. In this part we look at a running IR example and how it is transformed by our decompiler pipeline. Introducing The Example To demonstrate the utility of our IR, we have devised a slightly contrived example that nevertheless illustrates challenges encountered in real code.  The source of the example can be seen here:  https://github.com/tmikov/apple2tc/blob/master/blog/part6/ex.s . We assembled it with a6502: a6502 ex.s ex.b33 and disassembled it: apple2tc ex.b33 --asm > ex.lst Producing the following listing: /*0300*/ TSX /*0301*/ INX /*0302*/ INX /*0303*/ LDY M_0101,X ; $0101 /*0306*/ INY /*0307*/ STY M_90 ; $0090 /*0309*/ LDA M_91 ; $0091 /*030B*/ STA M_92 ; $009...

Apple2TC: an Apple II Binary to C Decompiler - Part 6, The IR

 This is part 6 in a series of posts describing Apple2TC.  The start is in  Part 1 . Part 5 described getting two Apple II games to work when decompiled in "Simple C" mode. In this part, we introduce our new Intermediate Representation (IR) of the disassembled code, which unlocks much more sophisticated analysis and finally puts us on the road to real  decompilation. What is an IR? An IR is a way to represent executable code as a data structure in memory, in a manner that makes its semantics explicit, and thus easier to analyze and transform. Typically, one or more forms of IR are used by optimizing compilers to represent and optimize the source code they are given. We are coming from the opposite direction - we need to represent code that has already been compiled - but there is little difference. The same principles apply. Wikipedia has a high level article about Intermediate Representation , which, while not very informative on its own, can be used as a starting ...