path: root/quine.asm

;;; QUINE
;;;
;;; This file is formatted to be read at 80-columns or wider.


;;;;;;;;;;;;;;;;;;;;;
;;; Workflow tips ;;;
;;;;;;;;;;;;;;;;;;;;;
;;;
;;; Currently, this is not yet fully self-hosting; it is based on
;;; flatassembler[1]. A minimal command to build and run it is:
;;;
;;; fasmg quine.asm quine && chmod 755 quine && ./quine; echo $?
;;;
;;; A workflow you may wish to use for debugging is:
;;;
;;; rm quine2; fasmg quine.asm quine && ./quine > quine2; echo "exit code:" $?; echo; hexdump -C quine; echo; hexdump -C quine2; echo; cmp quine quine2 ; echo cmp: $?
;;;
;;; The reason this removes the old one first is that otherwise, there's a
;;; risk the error message will be scrolled off the top of the screen and
;;; you'll see stale output and not realize.
;;;
;;; You may also wish to do:
;;;
;;; objdump --disassemble quine
;;; ZydisDisasm -64 quine
;;;
;;; This relies on GNU binutils, and on zydis, respectively.
;;;
;;; [1] https://flatassembler.net/


;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Assembly language ;;;
;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; Before doing any actual code, we define macros for writing x86-64 assembly
;;; language. This is built from scratch, relying only on flatassembler's
;;; built-in semantics. No include files of any kind are used for it.

macro rex.0
  db 0x40
end macro

macro rex.w
  db 0x48
end macro

macro rex.xb
  db 0x43
end macro

macro modrm mod, reg, rm
  assert mod >= 0 & mod < 4
  assert reg >= 0 & reg < 8
  assert rm >= 0 & rm < 8
  db (mod shl 6) or (reg shl 3) or rm
end macro

macro sib scale, index, base
  assert scale >= 0 & scale < 4
  assert index >= 0 & index < 8
  assert base >= 0 & index < 8
  db (scale shl 6) or (index shl 3) or base
end macro

macro opcodereg opcode, reg
  assert opcode >= 0 & opcode < 256 & opcode and 7 = 0
  assert reg >= 0 & reg < 8
  db opcode or reg
end macro

macro qwordreg result, register
  match =rax?, register
    result = 0
  else match =rcx?, regiser
    result = 1
  else match =rdx?, register
    result = 2
  else match =rbx?, register
    result = 3
  else match =rsp?, register
    result = 4
  else match =rbp?, register
    result = 5
  else match =rsi?, register
    result = 6
  else match =rdi?, register
    result = 7
  else
    assert 0
  end match
end macro


; TODO what register size does this use?
macro mov.b target, source
  match =rax?, target
    db 0xB8
    dd source
  else match =rdi?, target
    db 0xBF
    dd source
  else
    assert 0
  end match
end macro


; TODO what register size does this use?
macro mov.dreg.dimm target, source
  rex.w
  db 0xC7
  qwordreg reg, target
  modrm 3, 0, reg
  dd source
end macro


macro mov.qreg.qimm target, source
  rex.w
  qwordreg treg, target
  opcodereg 0xB8, treg
  dq source
end macro


macro mov.qreg.qreg target, source
  qwordreg treg, target
  qwordreg sreg, source
  rex.w
  db 0x89
  modrm 3, sreg, treg
end macro


; Take a 64-bit source register, treat it as an address and look up the 64-bit
; value it points to, store that into a 64-bit target register. The only modes
; available also have displacement; we use an 8-bit one and set it to zero.
;
; In understanding this, pay close attention to the Op/En column in the opcode
; table. The "RM" variant means the ModRM byte's R/M field (the third one)
; is the source, while its reg field (the middle one) is the target. This is
; what we want, because the R/M field is the one that gets indirection applied
; to it. Opcode 0x8B with an REX.W prefix is the all-64-bit RM variant.
; [Intel] volume 2B, chapter 3, section 3-4.3, "MOV".
;
; For the indirection modes, don't be confused by the many similar tables.
; 64-bit mode is encoded the same as 32-bit mode except for adding a REX.W
; prefix, as per 2.2.1.1, so you want table 2-2 to understand the ModRM byte.
; The presence or absence of an SIB byte is determined by where in that table
; we fall, and we aren't using a mode that has one. [Intel] volume 2A,
; chapter 2, section 2-1.5, table 2-2.
;
; We disallow rsp as a source because that's the mode that would want an SIB.
macro mov.qreg.indirect.qreg target, source
  match =rsp, source
    assert 0
  else
    qwordreg sreg, source
    qwordreg treg, target
    rex.w
    rb 0x8B
    modrm 1, treg, sreg
    db 0
  end match
end macro


; Take a 64-bit source register, store its value into the address pointed to
; by a 64-bit target register. The only modes available also have
; displacement; we use an 8-bit one and set it to zero.
;
; In understanding this, pay close attention to the Op/En column in the opcode
; table. The "MR" variant means the ModRM byte's reg field (the middle one)
; is the source, while its R/M field (the third one) is the target. This is
; what we want, because the R/M field is the one that gets indirection applied
; to it. Opcode 0x89 with an REX.W prefix is the all-64-bit MR variant.
; [Intel] volume 2B, chapter 3, section 3-4.3, "MOV".
;
; For the indirection modes, don't be confused by the many similar tables.
; 64-bit mode is encoded the same as 32-bit mode except for adding a REX.W
; prefix, as per 2.2.1.1, so you want table 2-2 to understand the ModRM byte.
; The presence or absence of an SIB byte is determined by where in that table
; we fall, and we aren't using a mode that has one. [Intel] volume 2A,
; chapter 2, section 2-1.5, table 2-2.
;
; We disallow rsp as a target because that's the mode that would want an SIB.
macro mov.indirect.qreg.qreg target, source
  match =rsp, target
    assert 0
  else
    qwordreg sreg, source
    qwordreg treg, target
    rex.w
    rb 0x89
    modrm 1, sreg, treg
    db 0
  end match
end macro


macro add.qreg.qreg target, source
  qwordreg treg, target
  qwordreg sreg, source
  rex.w
  db 0x01
  modrm 3, sreg, treg
end macro


; This adds a signed 8-bit immediate value to a 64-bit register, in place.
;
; Notice the use of 3 as the addressing mode. This says to use the register
; itself. The 0 in the reg field is part of the opcode.
macro add.qreg.bimm target, source
  qwordreg treg, target
  rex.w
  db 0x83
  modrm 3, 0, treg
  db source
end macro

; This adds a signed 32-bit immediate value to a 64-bit register, in place.
;
; Notice the use of 3 as the addressing mode. This says to use the register
; itself. The 0 in the reg field is part of the opcode.
macro add.qreg.dimm target, source
  qwordreg treg, target
  rex.w
  db 0x81
  modrm 3, 0, treg
  dd source
end macro

; This subtracts a signed 8-bit immediate value from a 64-bit register, in
; place.
;
; Notice the use of 3 as the addressing mode. This says to use the register
; itself. The 5 in the reg field is part of the opcode.
macro sub.qreg.bimm target, source
  qwordreg treg, target
  rex.w
  db 0x83
  modrm 3, 5, treg
  db source
end macro

; This subtracts a signed 32-bit immediate value from a 64-bit register, in
; place.
;
; Notice the use of 3 as the addressing mode. This says to use the register
; itself. The 5 in th reg field is part of the opcode.
macro sub.qreg.dimm target, source
  qwordreg treg, target
  rex.w
  db 0x81
  modrm 3, 5, treg
  dd source
end macro

; Move from an 8-bit immediate value, to a location relative to a 64-bit
; register, with an 8-bit displacement and no indexing.
;
; This uses opcode 0xC6, which has w = 0. Since we run in 64-bit mode, that
; makes the operand size 8 bits, regardless of the current operand-size
; attribute. [Intel] volume 2D, appendix B, section B-1.4.3, table B-6.
;
; TODO this should be mov.(something).disp8
macro mov.rel.b target, offset, source
  match =rsp, target
    db 0xC6
    modrm 1, 0, 4
    sib 0, 0, 4
    db offset
    db source
  else
    assert 0
  end match
end macro

; Move from a 16-bit immediate value, to a location relative to a 64-bit
; register, with an 8-bit displacement and no indexing.
;
; This uses opcode 0xC7, which has w = 1. We run in 64-bit mode, so that gives
; us an operand size of 32 bits by default. [Intel] volume 1, section 3.6.1,
; table 3-4. We want a 16-bit operand, so we use the operand-size prefix,
; 0x66, and we leave REX.W unset.
macro mov.rel.w target, offset, source
  match =rsp, target
    db 0x66
    db 0xC7
    modrm 1, 0, 4
    sib 0, 4, 4
    db offset
    dw source
  else
    assert 0
  end match
end macro

; Move from a 32-bit immediate value, to a location relative to a 64-bit
; register, with an 8-bit displacement and no indexing.
;
; This uses opcode 0x67, which has w = 1. We run in 64-bit mode, so that gives
; us an operand size of 32 by default. [Intel] volume 2D, section B.1.43,
; table B-6. This is what we want, so we leave it.
macro mov.rel.d target, offset, source
  match =rsp, target
    db 0xC7
    modrm 1, 0, 4
    sib 0, 4, 4
    db offset
    dd source
  else
    assert 0
  end match
end macro

; Move from a 64-bit register, to a 64-bit location relative to a 64-bit
; register, with an 8-bit displacement and no indexing.
;
; This uses opcode 0x89.
macro mov.rel.q target, offset, source
  match =rsp, target
    qwordreg sreg, source
    rex.w
    db 0x89
    modrm 1, sreg, 4
    sib 0, 4, 4
    db offset
  else
    assert 0
  end match
end macro

; Move from a 32-bit immediate value, to a 64-bit location relative to a
; 64-bit register, with an 8-bit displacement and no indexing.
;
; Note that there is no instruction to move a 64-bit immediate to memory.
;
; This uses opcode 0xC7, which has w = 1. We run in 64-bit mode, so that
; gives us an operand size of 32 by default. [Intel] volume 2D,
; section B.1.43, table B-6. We want a 64-bit operand, so we use the REX.W
; prefix, 0x48.
macro mov.rel.q.d target, offset, source
  match =rsp, target
    rex.w
    db 0xC7
    modrm 1, 0, 4
    sib 0, 4, 4
    db offset
    dd source
  else
    assert 0
  end match
end macro

; "Load effective address". Compute a 64-bit address as you would for
;  indexed addressing, with an 8-bit displacement and no indexing, but instead
; of doing anything with the memory, just store the address itself into a
; register.
macro lea.qreg.qreg.disp8 target, offset, source
  rex.w
  db 0x8D
  qwordreg treg, target
  qwordreg sreg, source
  modrm 1, treg, sreg
  db offset
end macro

; Clear the DF flag. This makes string instructions increment RSI.
macro cld
  db 0xFC
end macro

; Load 64 bits from the address in RSI into RAX. Then, increment or decrement
; RSI by 8 bytes, depending on the value of the DF flag.
macro lodsq
  rex.w
  db 0xAD
end macro

; Do an absolute indirect jump with a 64-bit register operand. That is: given
; a register which holds a pointer, read another address from the pointed-to
; memory and jump to it.
;
; Technically this is a "near" jump in x86 terms, but we just pretend far
; jumps and segments don't exist. They are still a thing in 64-bit mode, we
; just don't use them.
macro jmp.abs.indirect.qreg location
  db 0xFF
  qwordreg lreg, location
  modrm 0, lreg, 4
end macro

; Invoke a system call provided by the kernel. On Linux, the System V ABI
; describes the semantics of such calls (at least, on x86).
macro syscall
  db 0x0F, 0x05
end macro



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Executable file format ;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; Before we get into the body of the program, we do a lot of ELF-specific
;;; stuff to ensure that our output is in a format Linux knows how to run.
;;;
;;; First, we set the origin to load at. This is arbitrary, but it can't be
;;; zero. We tell flatassembler about it because it's used in label
;;; calculations; we can reference it as $$ any time we need it in future.
org 0x08000000

;;;
;;; Second, we output ELF's top-level file header.
;;;
elf_header:
  ; * denotes mandatory fields according to breadbox
  db 0x7F, "ELF"                 ; *magic number
  db 2                           ; 64-bit
  db 1                           ; little-endian
  db 1                           ; ELF header format version 1
  db 0                           ; System-V ABI
  db 8 dup 0                     ; (padding)

  dw 2                           ; *executable
  dw 0x3E                        ; *Intel x86-64
  dd 1                           ; ELF format version

  dq _start                      ; *entry point
  dq program_header - $$         ; *program header offset
  dq 0                           ; section header offset
  dd 0                           ; processor flags
  dw elf_header_size
  dw program_header_entry_size   ; *
  dw 1                           ; *number of program header entries
  dw 0                           ; section header entry size
  dw 0                           ; number of section header entries
  dw 0                           ; section name string table index
; Save a copy of the size of this chunk for our future reference, by comparing
; the current posiion to the label above.
elf_header_size = $ - elf_header

;;;
;;; Third, immediately after the ELF file header, we output ELF's program
;;; header, which lists the memory regions ("segments") we want to have and
;;; where we want them to come from. We list just a single region, which is
;;; the entire contents of the ELF file from disk.
;;;
;;; It would be more typical to have separate code and data segments, and
;;; perhaps a stack or heap, but this keeps things simple. We do have a little
;;; stack space available, though we don't explicitily request any; the kernel
;;; allocates it for us as part of exec() so that it can pass us argc and argv
;;; (which we ignore). That stack space will be at a random address, different
;;; every time, because of ASLR; that's a neat security feature, so we leave
;;; it as-is.
;;;
program_header:
  dd 1                           ; *"loadable" segment type
  dd 0x05                        ; *read+execute permission
  dq 0                           ; *offset in file
  dq $$                          ; *virtual address
                                 ;   required, but can be anything, subject to
                                 ;   alignment
  dq 0                           ; physical address (ignored)
  dq file_size                   ; *size in file
  dq file_size                   ; *size in memory
  dq 0                           ; segment alignment
                                 ;   for relocation - will we be ASLR'd?
; Save the size of this chunk, as well.
program_header_entry_size = $ - program_header


;;;;;;;;;;;;;;;;;;;;;;;
;;; Execution model ;;;
;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;;   We use Forth-style dual stacks, one for values and one for control. We
;;; use rsp for values, just like C does. We use rbp for the control stack,
;;; which is a special Forth-y stack: These are pointers into the bodies of
;;; Forth words, not return addresses.
;;;
;;;   The choice of rsp and rbp for the stack pointers imitates Jonesforth;
;;; I'm hopeful that it gives us convenient addressing modes, and will report
;;; back about that when I feel that I understand the implications.
;;;
;;;   In Forth, everything is a "word", including mutable variables.
;;; Conceptually, a word is a unit of execution, which may be implemented
;;; either in machine code or as an array of pointer to other words.
;;;
;;;   This polymorphism is implemented by having each word's contents begin
;;; with a "codeword", which is a pointer to machine code that "interprets"
;;; the rest of the contents. In the case of words implemented in machine
;;; code, the codeword points directly to that code, which is normally right
;;; next to it.
;;;
;;;   Variables, to Forth, are simply one more thing that can be executed; the
;;; effect of executing a variable is to push its address onto the value
;;; stack.
;;;
;;;   We adopt this model of words, codewords, and variables-as-words. It's
;;; nice for us because it works without a heap.
;;;
;;;   One way in which we differ from Forth is that we don't have a
;;; dictionary, and our words don't have names. Nothing would prevent this,
;;; it just isn't useful to this single-purpose program. The Forth dictionary
;;; is usually a linked list of every word that has ever been defined, with
;;; the newest at the head; the names of words are stored in string fields as
;;; part of every word's internal header. Our header has neither the pointer
;;; field for the dictionary, nor the string; the only header we have is the
;;; the codeword.
;;;
;;;   We specifically implement a version of calling and returning that Forth
;;; calls indirect threaded code: The control stack is a stack of pointers
;;; into the middle of interpreted words. The interpreter snippet, called
;;; DOCOL, implements calling.  Each word is responsible for making sure
;;; returning works properly. Interpreted words accomplish this by ending with
;;; the word EXIT, while machine-code words accomplish it by ending with a
;;; verbatim snippet called NEXT.
;;;
;;;   Conceptually, NEXT returns, but more specifically it accomplishes this
;;; by doing the caller's next dispatch for it; thus control never actually
;;; goes back to the caller's interpreter after initial setup. For performance
;;; reasons, NEXT is always inlined, so we define it as a macro.
;;;
;;;   DOCOL is just ordinary code, not a macro. It's defined later in this
;;; file, as a label.
;;;
;;;
;;;
;;; --------------------------------------------------------------------------
;;;  Quick Reference
;;; --------------------------------------------------------------------------
;;;
;;; The layout of an interpreted word:
;;;
;;;     0x00 - 0x08                     Codeword (address of DOCOL snippet)
;;;     0x08 - ???? (8-byte chunks)     Addresses of other words
;;;       ... (end)                     Address of EXIT word
;;;
;;; The layout of a machine-code word:
;;;
;;;     0x00 - 0x08                     Addresss of immediately following byte
;;;     0x08 - ????                     Arbitrary machine code
;;;       ... (end)                     Inlined implementation of NEXT
;;;
;;;
;;; REGISTER usage conventions:
;;;
;;; * rsi is the "instruction pointer" for the "interpreter".
;;;     That is, it points to some word-pointer inside an array of
;;;   word-pointers inside the content of the word they're part of. It always
;;;   points to the next word that should be executed, whose execution hasn't
;;;   begun yet.
;;;
;;; * rbp points to the top of the control stack
;;;     These are former values of rsi, to eventually be returned to, from
;;;   successively older callers as you look further up the stack. The stack
;;;   grows downwards in memory. Since values are kept separately, the only
;;;   thing on the control stack is return addresses, one per layer of call.
;;;
;;; * esp points to the top of the value stack
;;;     The value stack has no specific format, but it grows downwards in
;;;   memory. In particular there's no concept of stack frames, because items
;;;   on the stack don't belong to any particular word; the value stack in
;;;   Forth is in part a mechanism for passing values between words.
;;;
;;; Additionally, immediately after beginning execution of a word:
;;;
;;; * rax points to the address being executed
;;;     The value of rax is purely for the callee's benefit, and does not need
;;;   to be preserved.
;;;
;;;   Other registers are purely discretionary, and are not preserved across
;;; calls.
;;;
;;;
;;; FLAG usage:
;;;
;;; * DF should be 0
;;;   We use lodsq extensively and that makes it increment rsi after using it.
;;;
;;; --------------------------------------------------------------------------

;;;
;;; Macro NEXT
;;; ----------
;;;
;;;   Include this inline at the end of a word implemented in machine-code.
;;; Conceptually, it returns. What it actually does is do the next thing the
;;; caller would do, which is call the next word from the caller's array of
;;; word pointers.
;;;
;;; Registers in:
;;;
;;; * rsi points to the address of the word to execute
;;;
;;; Registers out:
;;;
;;; * rax points to the codeword in the contents of the word that was executed
;;; * rsi points to the next word-address after this one
;;;
;;; Flags
;;; * DF = 0 is required
;;;
macro NEXT
  ; Copy the next word's address from *rsi into rax. Increment the stack
  ; pointer (as per the DF flag).
  lodsq

  ; Load the codeword from the word's contents, and jump to the interpreter it
  ; points to.
  jmp.abs.indirect.qreg rax
end macro

;;;
;;; Macros PUSHCONTROL
;;;        POPCONTROL
;;; ------------------
;;;
;;;   Include these inline to push an address onto the control stack, or pop
;;; one off of it. You will recall the control stack is kept in rbp. The
;;; parameter is given in a user-specified register.
;;;
;;;   Jonesforth's analogous macros are called PUSHRSP and POPRSP but I think
;;; that's super confusing, since rsp is also the name of a register, but a
;;; different one. I guess it was less confusing in 32-bit, since esp doesn't
;;; start with an "r". Anyway, this has to be named something that
;;; distinguishes it from Intel's PUSH and POP opcodes, so...
;;;
;;;   "Load effective address" is just a cute way to do arithmetic on a
;;; register, here. To push or pop we decrement or increment rbp by 8. To
;;; actually interact with the space in the stack, we indirect through rbp.
;;;
;;; Registers in and out:
;;;
;;; * rbp points to the top of the control stack.
;;;
macro PUSHCONTROL source
  lea.qreg.qreg.disp8 rbp, -8, rbp
  mov.indirect.qreg.qreg rbp, source
end macro

macro POPCONTROL target
  mov.qreg.indirect.qreg target, rbp
  lea.qreg.qreg.disp8 rbp, 8, rbp
end macro

;;;
;;; Routine DOCOL
;;; -------------
;;;
;;;   Reference this via its label as the codeword of a word to make it an
;;; "interpreted" word. Concretely, it saves rsi (the "instruction pointer")
;;; to the control stack, takes the address of the codeword from rax and
;;; increments it in-place to form the new instruction pointer, and copies
;;; that to rsi.
;;;
;;;   Having then done this, we're now in the state that normal execution
;;; expects, so DOCOL ends by it using NEXT to begin the callee's execution,
;;; kicking off a nested call.
;;;
;;;   The name is said to be short for "do colon", because Forth high-level
;;; code begins word definitions with a colon.
;;;
;;; Registers in:
;;;
;;; * rsi is the caller's instruction pointer
;;; * rbp is the control stack pointer
;;; * rax is the address of the callee's codeword
;;;
;;; Registers out:
;;;
;;; * rsi is the callee's instruction pointer
;;; * rbp is the control stack pointer
DOCOL:
  PUSHCONTROL rsi
  add.qreg.bimm rax, 8
  mov.qreg.qreg rsi, rax
  NEXT

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Implementation strategy ;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;;   We assemble the entire file contents in a stack-allocated buffer.
;;; We avoid using the stack for any other purpose. When the file is fully
;;; assembled, we output it.
;;;
;;;   The assembly proceeds in several chunks - ELF header, program header,
;;; etc. Each chunk extends the buffer as per its own needs, by adjusting
;;; the stack pointer. All chunks also update a running total file size,
;;; which refers to how many bytes have actually been populated, not to the
;;; size of the buffer.
;;;
;;; Register usage:
;;;
;;; * rdx holds the total used file size so far. During hand-off between
;;;   chunks, this size must be equal to the buffer size; within a chunk it
;;;   may be less.
;;;
;;; * rsp points to the bottom of the buffer.
;;;
_start:
  ;;;
  ;;; Initialize registers
  ;;;
  cld                                      ; clear the DF flag
  mov.dreg.dimm rdx, 0                     ; store running file size here
  sub.qreg.bimm rsp, 0xFF                  ; reserve stack space

  ;;;
  ;;; ELF header
  ;;;
  mov.rel.d rsp, 0x00, 0x7F bappend "ELF"  ; magic number
  mov.rel.b rsp, 0x04, 2                   ; 64-bit
  mov.rel.b rsp, 0x05, 1                   ; little-endian
  mov.rel.b rsp, 0x06, 1                   ; ELF header format version 1
  mov.rel.b rsp, 0x07, 0                   ; System-V ABI
  mov.rel.q.d rsp, 0x08, 0                 ; (padding)

  mov.rel.w rsp, 0x10, 2                   ; executable
  mov.rel.w rsp, 0x12, 0x3E                ; Intel x86-64
  mov.rel.d rsp, 0x14, 1                   ; ELF format version

  ; Compute the entry pointer.
  mov.qreg.qimm rax, $$                    ; the memory origin
  add.qreg.bimm rax, 0x78                  ; the size of the headers
  add.qreg.dimm rax, 155                   ; the offset of _start
  mov.rel.q rsp, 0x18, rax                 ; entry point

  mov.rel.q.d rsp, 0x20, 64                ; program header offset
    ; We place the program header immediately after the ELF header. This
    ; offset is from the start of the file.
  mov.rel.q.d rsp, 0x28, 0                 ; section header offset
  mov.rel.d rsp, 0x30, 0                   ; processor flags
  mov.rel.w rsp, 0x34, 64                  ; ELF header size
  mov.rel.w rsp, 0x36, 56                  ; program header entry size
  mov.rel.w rsp, 0x38, 1                   ; number of program header entries
  mov.rel.w rsp, 0x3a, 0                   ; section header entry size
  mov.rel.w rsp, 0x3c, 0                   ; number of section header entries
  mov.rel.w rsp, 0x3e, 0                   ; section name string table index

  ; Add the size of the ELF header to the running total
  mov.dreg.dimm rax, 0x40
  add.qreg.qreg rdx, rax

  ;;;
  ;;; Program header
  ;;;
  mov.rel.d rsp, 0x40, 1                   ; "loadable" segment type
  mov.rel.d rsp, 0x44, 0x05                ; read+execute permission
  mov.rel.q.d rsp, 0x48, 0                 ; offset in file
  mov.rel.q.d rsp, 0x50, $$                ; virtual address
    ; required, but can be anything, subject to alignment
  mov.rel.q.d rsp, 0x58, 0                 ; physical address (ignored)

  ; Fill in 0 as the file size for now, to avoid unitialized memory.
  mov.rel.q.d rsp, 0x60, 0                 ; size in file
  mov.rel.q.d rsp, 0x68, 0                 ; size in memory

  mov.rel.q.d rsp, 0x70, 0                 ; segment alignment
    ;   for relocation - will we be ASLR'd?

  ; Add the size of the program header to the running total
  mov.dreg.dimm rax, 0x38
  add.qreg.qreg rdx, rax

  ;;; Hardcode the size of the actual code chunk, since we don't yet have a
  ;;; way to generate it.
  ;;;
  ;;; TODO of course, really we want to for-real track this
  mov.qreg.qimm rax, 0x200
  add.qreg.qreg rdx, rax

  ;;;
  ;;; Go back and fill in the file size now that we know it.
  ;;;
  mov.rel.q rsp, 0x60, rdx                 ; size in file
  mov.rel.q rsp, 0x68, rdx                 ; size in memory

  ;;;
  ;;; The buffer is ready; output the file.
  ;;;

  ; write() from stack-allocated buffer
  mov.b rax,1
  mov.qreg.qimm rdi, 1
  mov.qreg.qreg rsi, rsp
  mov.qreg.qimm rdx, 0x78
  syscall

  ; write() the machine code by using self-reference
  ;
  ; TODO do this in a "real" quine way
  mov.b rax, 1
  mov.qreg.qimm rdi, 1
  mov.qreg.qimm rsi, elf_header + 0x78
  mov.qreg.qimm rdx, file_size - 0x78
  syscall

  ;;;
  ;;; Clean up.
  ;;;

  ; exit()
  mov.b rax, 60
  mov.b rdi, 0
  syscall

file_size = $ - $$