1. 10
  1.  

  2. 3

    The headline is kind of clickbait-y, IMO. It’s only assembling a tiny subset of x86 assembly, and as akavel mentioned, it’s not even parsing input files. It’s a neat library, but it’s not “an x86 assembler” as most people would think of one.

    Since it’s somewhat on topic, SBCL Common Lisp comes with a library for emitting (and running) assembly language, and IIRC it can even alter the code generated by the compiler at runtime: https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/

    1. 0

      Yeah, it is a BS headline. Thanks for the link. That’s pretty cool.

    2. 2

      Maybe worth to note that it’s an assembler in a library form, i.e. without code for a parser. Looking at it in another way, it’s a clever reuse of the C compiler’s parser!

      Now, in a something of a “shameless plug”, incidentally I took a very similar approach recently, going for a “library form” too when writing an experimental assembler for Dalvik (i.e. Android VM) bytecode.

      1. 1

        Compiler eDSLs are very cool! You get to keep all the nice features of the host language without incurring any runtime overhead in the target language. It looks very tidy in a language with objects or do-notation, too.

        As an unnecessarily extreme example, I once wrote one of these in Idris, targeting Lua. It was great to have static type checking for free in a Lua program. I’m also thinking about ways of eliminating the “run” step, since you’re actually writing a program that you have to run to output the real program.

        1. 3

          In case of Lua, do you know about Terra language? I think they did something very much like what you describe w.r.t. the “run” part. edit: At least the “2nd” run. IIUC you may mean it about the “1st” run.

          1. 1

            I’d heard of it but not looked at it in depth. Definitely going to spend some time absorbing its ideas.