Dissecting the TLS EMIT Dialect

Oldes looked at the TLS 1.2 code I wrote and so he saw the EMIT dialect, and he followed some of the idea. He seemed to get a pretty compact implementation in his rewrite, so I meant to look into it, but I hadn't.

So since I'm writing a post on this dialect concept, here is his spin... "bincode".

It's a native function in C, named BINARY.

The dialect alternates size and signedness indicators with values. He doesn't use any labels unless he's actually going to read or write them. And he does a lot of the math with "magic numbers" vs. explaining the source of those numbers. So most examples don't have labels, but here's one that does:

binary/write out [
    UI8  22          ; protocol type (22=Handshake)
    UI16 :version    ; protocol version
  pos-record-len:
    UI16 0           ; length of the (following) record data
  pos-record:
    UI8  16          ; protocol message type (16=ClientKeyExchange)
  pos-message:
    UI24 0           ; protocol message length
  pos-key: 
]

The dialect doesn't use the evaluator unless you put in a GROUP!. So you couldn't say UI8 20 + 2 above in place of UI8 22. You would have to say UI8 (20 + 2)

While there's benefits and drawbacks to both general approaches, his approach hinges on a lot of native code...see %u-bincode.c - that's just not going to be the solution for the average DSL author. (Note on the C code: I think I truly can say that he is carrying the torch for the style in which it was originally written. He has my blessing as being the rightful maintainer of R3-Alpha.)

But the key point to the discussion is that he didn't try the same thing of mixing evaluations...the code is quarantined in GROUP!s.