"Gene Therapy Extends Mouse Wingspan"

You don't "switch" to IPv6, you add IPv6. Nobody expects IPv4 to go away any time soon. What everyone's talking about is supporting IPv6 plus IPv4. So all your old sites work, but you can also reach any new hosts that have IPv6 addresses only directly, and get the benefits of avoiding NAT. Those hosts will likely be mobile customers at first, since that's one of the first places where ISPs are having to use v6. As for those users, they will be able to talk to IPv4 sites via DNS trickery and IPv6-to-IPv4 NAT, or just via plain old IPv4 NAT.

So you expect a virtual AVR running on Java running on a real ARM to be a 5x speedup over native code, even though your massively more powerful PC could barely manage 5x real time speed emulating the same AVR?

Sorry, that's not how it works.

Although it is theoretically possible for a very optimized emulator/dynamic translator to be faster at running poorly optimized native code on the same CPU than the actual CPU itself (by optimizing it), I'm not aware of any circumstances where something like this has actually been used in practice and been useful. And certainly not anything written in Java. The closest thing I've heard of were x86 emulators for Itanium beating the Itanium's built-in x86 support, but the emulators were of course translating to IA64, not to x86, so it doesn't count.

From TFA:

Where the form says “Comment number(s) of proposed classes of works to which you are responding,” enter a “3” if you’re writing about game consoles or a “5” if you’re writing about smartphones or tablets. You might consider also entering a "4" to submit your comments in support of an exemption request proposed by the Software Freedom Law Center to allow jailbreaking of "personal computing devices."

Sounds like you want to support comment "4", which is the SFLC's attempt at getting *all* personal computer devices exempted.

I am getting the impression that there is an "self.ip += 1" missing in the implementation of the jmp(e) when mod == 1.

You're right. The problem isn't the lack of "self.ip += 1" inside the condition (that would do nothing, as the branch target specifies the new value for self.ip anyway); the problem is that when a conditional branch with mod == 1 isn't taken, the second byte is executed as a new instruction instead of skipped. I guess this variant isn't used in the provided bytecode so it didn't break things.

I agree that code useful in the long term should be easy to read, but the chances of me wanting to go back to this code in the future are very, very slim, so I didn't bother with that aspect.

Well, if JavaScript is the language that you're most familiar and comfortable with, and you're happy using a browser or you have a commandline JS interpreter handy, then by all means. I personally prefer Python of course, but everyone has a different taste in programming languages. However, what makes no sense is writing it in JS just because the original file ends in .js. That little fact should have exactly zero influence on the choice of language that you do pick to implement this in.

Considering the parent switched to C++ though, it seems the he hit some kind of snag. If JS is his preferred scripting language then I wouldn't expect him to switch to something else when he has trouble, that's why I kind of assumed that he picked JS just because the original file happened to be JS and not because it's what he finds easiest.

FWIW, my Python version is about 2.5x shorter than TFA's version (counting only the actual code, not the memory block or comments), though I went for a quick and dirty, shortest and simplest version that would do the job, without attempting to make it pretty-print instructions or do anything fancy, and without giving much though to readability (it was meant as a throwaway implementation that I could expand upon if I needed to analyze execution in more detail - thankfully, that wasn't needed and after adding a couple debug prints I was able to iron out a bug or two and it just worked).

Well... I do know someone who is capable of staring at an unknown, undocumented binary blob for a new/proprietary architecture and working out enough of the ISA to write a fairly comprehensive disassembler and then an emulator. Just by staring at the hex and making educated guesses as to what each opcode means, which he later refines as he makes sense of the program. How he can do that boggles the mind, but he can (I've seen him do it at least three times already).

I don't know if the intelligence agencies happen to employ anyone like him though.