I also wrote an unofficial tutorial here: http://blog.reverberate.org/2012/12/hello-jit-world-joy-of-s...

These docs look pretty nice, particularly the "reference" part. It's probably the first time anyone has attempted to comprehensively explain all of DynASM's concepts in detail, and contains answers to several questions that I previously had to email Mike Pall directly about.

Tangentially: I am interested in sponsoring an open source (Apache License) implementation of BPF bytecode in DynASM (or LuaJIT). The use case is to execute packet filters compiled by libpcap. Ideally we'd win shootouts (like http://carnivore.it/2011/12/28/bpf_performance).

Get in touch if you are the person to do this :-) luke@snabb.co

Hi Luke, Take a look at bpfjit in NetBSD. It uses bsd licensed sljit library to generate code for multiple platforms. The library has some slight overhead over hand-written assembly but it gives you a single codebase for all platforms. At the very least, you can borrow some optimisations from my code. http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/bpfjit.c?onl... PS I can't work on sponsored projects. Alex

Thanks for the pointer!

Do you also know a lightweight way to compile pcap-filters into BPF code?

Not sure there is. There seems to be a lot of optimisation done, and there only seem to be a couple of heavyweight implementations.

From my humble experience, even the simplest implementations of BPF runtime are fast enough. Maybe just jitted interpreter in LUA would do for most use cases.

BPF is generally pretty fast.

Great work Peter!

This would have been perfect when I was trying to get my head around how DynASM works.

I should try and pick it up again soon..... (if only there was time!)

I continue to wonder why No one has ever used it as part of the CPython / CRuby compiler?

For a JIT for a complex dynamic language like Python and Ruby, emitting the machine code is not a significant part of the problem. The problem is in choosing which instructions to emit, and other things like transitioning between different stacks and how you store your objects. I don't think DynASM helps with those problems.

For Python: likely because the few people who need a faster Python, have the JIT experience to build one, and have the time and/or funding to do so, are working on PyPy.

And adding to that: the reason why things like LLVM come up a lot is because, if you write your chain right, you get things like LLDB for free. Using DynASM as your JIT base still forces you to write GDB hooks or a custom debugger, which, while hardly impossible, also aren't the easiest thing in the world. I actually think DynASM is a lot easier to wrap your head around on the JIT landscape, but it's also much more suited to a build-the-world type of situation.