This is a quick overview of this month’s open source contributions I managed to get in.

  • DmitrySoshnikov/hdl-js: Added tests for Decoder gate1: This is a follow-up for a pull request I made in January2. It adds test for some demo/example code I added to the project.

  • DmitrySoshnikov/hdl-js: Implement 1bit MipsAlu as built-in gate3: This PR adds a built-in gate to the hardware description language. It behaves like a Mips ALU but only on one bit operands. The idea is that multiple of these can be stacked together to form an ALU that operates on full words. This code was interesting to write, because the project already had the gate implement in hdl-js as an example. It was sort of reverse-reverse-engineering since I wrote a JavaScript gate implementation modeled after a gate implemented in hdl-js which executes the hardware logic in JavaScript. Fun stuff!

  • xtuc/js-webassembly-interpreter: Implement reinterpret for f64 nans4: This and the next PR were the most fun open source work I did this month I think. The goal of it is to support nan and inf values in the reinterpret instruction. What does that mean? Reinterpretation means you take the bits of a floating point value and read them as integer instead. For number values JavaScript has this functionality built in via typed arrays. Basically, you can write a floating point number to a typed array and then read it as integer. However, special values are not supported in this conversion mechanism so I added the raw bit manipulations for these cases. The fun part about this project is that there are lots and lots of “official” tests5 that you can run your code against.

  • xtuc/js-webassembly-interpreter: Reinterpret inf in f32 and f646: This works on exactly the same problem as above. I split the work into two pull requests because the project moves fast and larger PRs will create too much merging overhead.

Note that js-webassembly-interpreter was renamed to webassemblyjs.

  • babel/minify: Use hexadecimal notation for number literals when shorter7: When looking through the minifier code for other posts89, I saw how number literals are potentially minified by using exponential representation. Powers of ten are the canonical example where this applies, 1000000000 becomes 1e9 for example. The base is 10 using this notation, but in fact hexadecimal with 16 has a larger base. A larger base generally means shorter representation, so I started searching for numbers whose hexadecimal representation is shorter than the decimal (and exponential) one. As so often, somebody on stackoverflow has already done the hard work and found that these number ranges exist10. My pull request then only contains the easy part which is computing the hexadecimal representation (Number.prototype.toString(16)) and comparing its length to the others. Why is it not merged? It is about gzip compression which seems to deal better with decimals than hexadecimals. Join the discussion on GitHub if you have any thoughts on this!