3 ms·

I'm not faulting the BPF authors for not inventing DynASM, I'm just illustrating what DynASM buys you over the more traditional approach. Without a preprocesso

I'm not faulting the BPF authors for not inventing DynASM, I'm just illustrating what DynASM buys you over the more traditional approach. Without a preprocessor you'll always be dealing in encoded instructions instead of symbolic ones. It's manual work that is surely nicer to avoid if you can. I'm surprised that you're put off by the preprocessor aspect of it, given the benefits of this approach.

tptacek 14y ago
There's something to be said for instructions encoded into structs instead of raw assembly; those structures are parameterized, so it's easy to interrogate them or bind new values to them; without structures, you end up having to invent new assembly language features for dynamic labels and things like that.
- haberman 14y ago
  > There's something to be said for instructions encoded into structs instead of raw assembly I'm confused, what is this in response to? Are we still talking about BPF's JIT vs DynASM? By "instructions encoded into structs" are you referring to BPF's byte-code? I'm certainly not arguing against a byte-code approach at all -- byte-code obviously has numerous advantages, including (as you mention) ease of inspection. Even LuaJIT (the project that DynASM was built for) uses byte-code pervasively. The question is: at the point that you decide you want to generate machine code from your byte-code, what's the easiest way to do it? The BPF JIT's code is functionally identical to a DynASM-based code generator; the only difference is that the BPF JIT requires a human to put the machine encoding of every instruction directly in the source file. DynASM saves the human from performing this step by using a preprocessor.
  - tptacek 14y ago
    No, I'm saying, rather than have the representation of assembly code in your C program be textual --- raw assembly code interpolated into C code and expanded into structs by a preprocessor --- there is something to be said for having the representation of your instructions be "native", expressed without a preprocessor. In particular, it makes it easier to modify the assembly code in C code later on in the runtime of the program; and, if you look closely at things like DynASM, it's not "really" assembly qua assembly, because they've added features to the language to handle the dynamic things anyways. I'm definitely not saying bytecode is better than assembly code! I'm talking strictly about the mechanism by which you generate opcodes from "assembly language". A library that can generate opcodes without exposing all the fiddly mod/rm stuff is probably just as good as the preprocessor tool. I am, like everyone else, appropriately reverential of LuaJIT. :)
    - haberman 14y ago
      > A library that can generate opcodes without exposing all the fiddly mod/rm stuff is probably just as good as the preprocessor tool. I'm skeptical that such a library could have a very simple or clean interface -- the "mov" instruction alone has almost 40 variants, all encoded in different ways -- but if you ever create such a thing I promise to check it out and give it a fair opinion. :)
      - tptacek 14y ago
        Most of the x64 instruction set shares a common set of addressing mode variants all encoded the same way. I've done this from C (messily) and from Ruby (very cleanly) and while the x64 ISA is definitely a pain to work with directly, it's not so painful that I think it defies the abstractions C provides natively. :)

tptacek 14y ago

There's something to be said for instructions encoded into structs instead of raw assembly; those structures are parameterized, so it's easy to interrogate them or bind new values to them; without structures, you end up having to invent new assembly language features for dynamic labels and things like that.

haberman 14y ago
> There's something to be said for instructions encoded into structs instead of raw assembly I'm confused, what is this in response to? Are we still talking about BPF's JIT vs DynASM? By "instructions encoded into structs" are you referring to BPF's byte-code? I'm certainly not arguing against a byte-code approach at all -- byte-code obviously has numerous advantages, including (as you mention) ease of inspection. Even LuaJIT (the project that DynASM was built for) uses byte-code pervasively. The question is: at the point that you decide you want to generate machine code from your byte-code, what's the easiest way to do it? The BPF JIT's code is functionally identical to a DynASM-based code generator; the only difference is that the BPF JIT requires a human to put the machine encoding of every instruction directly in the source file. DynASM saves the human from performing this step by using a preprocessor.
- tptacek 14y ago
  No, I'm saying, rather than have the representation of assembly code in your C program be textual --- raw assembly code interpolated into C code and expanded into structs by a preprocessor --- there is something to be said for having the representation of your instructions be "native", expressed without a preprocessor. In particular, it makes it easier to modify the assembly code in C code later on in the runtime of the program; and, if you look closely at things like DynASM, it's not "really" assembly qua assembly, because they've added features to the language to handle the dynamic things anyways. I'm definitely not saying bytecode is better than assembly code! I'm talking strictly about the mechanism by which you generate opcodes from "assembly language". A library that can generate opcodes without exposing all the fiddly mod/rm stuff is probably just as good as the preprocessor tool. I am, like everyone else, appropriately reverential of LuaJIT. :)
  - haberman 14y ago
    > A library that can generate opcodes without exposing all the fiddly mod/rm stuff is probably just as good as the preprocessor tool. I'm skeptical that such a library could have a very simple or clean interface -- the "mov" instruction alone has almost 40 variants, all encoded in different ways -- but if you ever create such a thing I promise to check it out and give it a fair opinion. :)
    - tptacek 14y ago
      Most of the x64 instruction set shares a common set of addressing mode variants all encoded the same way. I've done this from C (messily) and from Ruby (very cleanly) and while the x64 ISA is definitely a pain to work with directly, it's not so painful that I think it defies the abstractions C provides natively. :)