That's a tricky one because there is no "assembly language", so much as N different ways of mapping text onto numbers that a processor can interpret. First the

That's a tricky one because there is no "assembly language", so much as N different ways of mapping text onto numbers that a processor can interpret. First the target instruction set changes. You may have a `mov` for copying between registers but you may not. For that matter, you may not have registers. You probably can write raw bytes in the middle of an instruction stream for instructions that the assembler doesn't know about, and if you wrote the entire program like that, you'd (almost) have the binary itself. Then there are common conventions like `label:` and being able to write basic arithmetic in a place that an instruction expects an immediate operand, but they're at the whim of whoever wrote the assembler. There's probably a macro layer or two. There is a strong analogy remaining though. Some creator gave us the processor, with documentation of some quality about how to make the piece of sand do anything, and on top of that someone (who may have been the same creator but may not) usually writes mnemonics for the instruction set and from that, an assembler. The core holy text for a given processor is then something like https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf https://developer.amd.com/wp-content/resources/Vega_Shader_I... - an incomplete description of what the magic sand does, from which one who is sufficiently determined can construct arbitrary computation.