5 ms·

> Even assembly language is an abstraction Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstracti

> Even assembly language is an abstraction Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstraction, it would be an interface.

Spivak 4y ago
Nope, the CPU presents you an interface of the available instructions but those instructions are a complete fiction on modern processors and don't have to match at all what the underlying hardware does. The CPU guarantees that the observable effects of the instructions are consistent (i.e if the processor wants to do some fuckery it can't change the instruction semantics) but beyond that is free to run your code however it wants.
- nine_k 4y ago
  Simpler RISC designs, like simpler ARM cores, more or less directly execute instructions; same for old 8-bit cores you can still widely find in MCUs. Complex high-performance cores, with pipelining, instruction fusion, and OoO execution, turn instruction stream into a microcode lava.
  - Spivak 4y ago
    So maybe the right thing to say is that assembly is a contract between you and the processor and the underlying implementation can map directly to hardware when appropriate but it doesn't have to. It is an abstraction over different underlying hardware implementations.
nine_k 4y ago
First of all, you normally use symbolic labels, not offsets for jumps; the assembler will calculate them for you, and a linker will possibly build a relocation table based on them. Then, any good assembler has macros. Also, data / text blocks, etc that are not code but an abstraction which the linker later uses. Writing machine code directly, as a byte stream, is fun, but is exhausting.
- ilyt 4y ago
  Arguably it's more of translation layer not abstraction. You're not abstacting away any concepts or code blocks here, you still have to write every single instruction, you just get a bit of a help with math.
  - constantcrying 4y ago
    Assemblers like nasm have an entire macro language. Of course that isn't part of the ISA. But in the end even the ISA is fiction.
constantcrying 4y ago
>I thought assembly mapped 1-to-1 with actual HW instructions. Assembly encodes a wide varity of abstractions (it is a human readable format after all) and lots of assembly instructions have a clear relation to an instruction on the hardware, but definitely not all. E.g. a CPU does not understand what a "label" is and the semantics of a labels and jumping to them is removed by the assembler. But not even the assembled binary actually maps to executed instructions. The CPU is actually a virtual machine which presents itself as e.g. an x86 ISA interpreter, but internally it uses microcode executed in various performance enhancing ways to speed up the process.
chacham15 4y ago
It is true. Abstraction means that you dont have to worry about some lower level concerns. With computers, the rabbit hole goes quite deep. High-level language (C/python) Assembly language (att/intel) Byte code Micro code So, with assembly code, you dont care about what the actual bytes that get generated are (they can change and you'd never know if the system was backwards compatible). Similarly, if the microcode that the CPU generates to implement the instruction changes youd also never know.
eterm 4y ago
If you're not manually setting voltages on different pins then at some level it's an abstraction.
- deleted 4y ago
  [deleted]
deckard1 4y ago
> I thought assembly mapped 1-to-1 with actual HW instructions. on x86 it's a 1-to-many relationship. There are, for example, many different MOV instructions that can be encoded based on the parameters used. All assemblers I know of hide this from the user, as well as featuring labels, macros, etc. which are not defined by the hardware at all. For the most part, the x86 assembler hides the details of prefix bytes and ModR/M+SIB from the user. Some assemblers are quite advanced and if you took them just a few logical steps beyond where they are you would end up with C.
pclmulqdq 4y ago
This is true. Ignoring the labels, macros, and directives, there are many ways in machine code to encode most common x86 instructions (zeroing a register even has many possible assembly instructions!). Assemblers pick the best encoding.
- unwind 4y ago
  Is that true? They swap actual instruction mnemonics as written in the assembly source into different instructions, for performance? I hope that is controlled by some flag or something, seems like a strange thing for an assembler to be doing unless asked. I seem to remember the venerable combined assembler/monitor/editor ASM-One [1] on the Amiga having a mode to do that, an "optimizing assembler", but I think it mainly worked with instruction and data sizes, i.e. optimizing short jumps into branches which were cheaper on the 68k. [1]: https://en.wikipedia.org/wiki/ASM-One_Macro_Assembler https://en.wikipedia.org/wiki/ASM-One_Macro_Assembler
  - pclmulqdq 4y ago
    I believe that there are some assemblers that will swap "mov rax, 0" for "xor eax, eax" (which is smaller and faster), if you let them, but not all of them. Some instructions like "jmp LABEL" correspond to many different options (short relative jumps, long relative jumps, absolute jumps, etc.) and the assembler picks the best one. As another example, almost all of the vector instructions have an encoding with a VEX prefix (an AVX encoding) as well as the older SSE encoding. If you mix the VEX and SSE encoded instructions, there can be a big slowdown, so an assembler will give you VEX encodings if you have AVX-only instructions in the stream, and default to SSE encodings if you don't (they are often smaller). Some instructions, like LEAs and ADDs, have several different encoding options corresponding to different operand orderings, and an assembler will pick the best one - some of these encodings will force an extra SIB byte when you use R12 as an operand, for example. This is kind of assembler-specific in terms of how smart it is. I'm not sure that the dumber assemblers do this for you.
littlestymaar 4y ago
> Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstraction, it would be an interface. Assembly gives you a nice sequential list of instructions, completely hiding pipelining, speculative execution, and all the magic that modern (since the 90s at least) CPU do to do the job fast. And as the Spectre family of CPU vulnerabilities, these abstractions are in fact more leaky than most people assume.
- trashtester 4y ago
  And cache management, thread switching optimization/prioritization, and so on. If a CPU were to ONLY do the instructions that were written in the assembly code, the code could be maybe 5-10 times slower when using cached memory and 100x slower if accessing RAM constantly. And this is part of the reason why it's hard to write assembly that is faster than a well optimized C/C++ program. The C compiler "knows" (to some extent) what the machine code leads to at the hardware level, and will often create machine code that is more liklely to allow the CPU to reap all such advantages in a way many assembly programmers wouldn't know about or think of.

> Even assembly language is an abstraction Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstraction, it would be an interface.

Spivak 4y ago

Nope, the CPU presents you an interface of the available instructions but those instructions are a complete fiction on modern processors and don't have to match at all what the underlying hardware does. The CPU guarantees that the observable effects of the instructions are consistent (i.e if the processor wants to do some fuckery it can't change the instruction semantics) but beyond that is free to run your code however it wants.

nine_k 4y ago
Simpler RISC designs, like simpler ARM cores, more or less directly execute instructions; same for old 8-bit cores you can still widely find in MCUs. Complex high-performance cores, with pipelining, instruction fusion, and OoO execution, turn instruction stream into a microcode lava.
- Spivak 4y ago
  So maybe the right thing to say is that assembly is a contract between you and the processor and the underlying implementation can map directly to hardware when appropriate but it doesn't have to. It is an abstraction over different underlying hardware implementations.

nine_k 4y ago

First of all, you normally use symbolic labels, not offsets for jumps; the assembler will calculate them for you, and a linker will possibly build a relocation table based on them. Then, any good assembler has macros. Also, data / text blocks, etc that are not code but an abstraction which the linker later uses. Writing machine code directly, as a byte stream, is fun, but is exhausting.

ilyt 4y ago
Arguably it's more of translation layer not abstraction. You're not abstacting away any concepts or code blocks here, you still have to write every single instruction, you just get a bit of a help with math.
- constantcrying 4y ago
  Assemblers like nasm have an entire macro language. Of course that isn't part of the ISA. But in the end even the ISA is fiction.

constantcrying 4y ago

>I thought assembly mapped 1-to-1 with actual HW instructions. Assembly encodes a wide varity of abstractions (it is a human readable format after all) and lots of assembly instructions have a clear relation to an instruction on the hardware, but definitely not all. E.g. a CPU does not understand what a "label" is and the semantics of a labels and jumping to them is removed by the assembler. But not even the assembled binary actually maps to executed instructions. The CPU is actually a virtual machine which presents itself as e.g. an x86 ISA interpreter, but internally it uses microcode executed in various performance enhancing ways to speed up the process.

chacham15 4y ago

It is true. Abstraction means that you dont have to worry about some lower level concerns. With computers, the rabbit hole goes quite deep. High-level language (C/python) Assembly language (att/intel) Byte code Micro code So, with assembly code, you dont care about what the actual bytes that get generated are (they can change and you'd never know if the system was backwards compatible). Similarly, if the microcode that the CPU generates to implement the instruction changes youd also never know.

eterm 4y ago

If you're not manually setting voltages on different pins then at some level it's an abstraction.

deleted 4y ago
[deleted]

deckard1 4y ago

> I thought assembly mapped 1-to-1 with actual HW instructions. on x86 it's a 1-to-many relationship. There are, for example, many different MOV instructions that can be encoded based on the parameters used. All assemblers I know of hide this from the user, as well as featuring labels, macros, etc. which are not defined by the hardware at all. For the most part, the x86 assembler hides the details of prefix bytes and ModR/M+SIB from the user. Some assemblers are quite advanced and if you took them just a few logical steps beyond where they are you would end up with C.

pclmulqdq 4y ago

This is true. Ignoring the labels, macros, and directives, there are many ways in machine code to encode most common x86 instructions (zeroing a register even has many possible assembly instructions!). Assemblers pick the best encoding.

unwind 4y ago
Is that true? They swap actual instruction mnemonics as written in the assembly source into different instructions, for performance? I hope that is controlled by some flag or something, seems like a strange thing for an assembler to be doing unless asked. I seem to remember the venerable combined assembler/monitor/editor ASM-One [1] on the Amiga having a mode to do that, an "optimizing assembler", but I think it mainly worked with instruction and data sizes, i.e. optimizing short jumps into branches which were cheaper on the 68k. [1]: https://en.wikipedia.org/wiki/ASM-One_Macro_Assembler https://en.wikipedia.org/wiki/ASM-One_Macro_Assembler
- pclmulqdq 4y ago
  I believe that there are some assemblers that will swap "mov rax, 0" for "xor eax, eax" (which is smaller and faster), if you let them, but not all of them. Some instructions like "jmp LABEL" correspond to many different options (short relative jumps, long relative jumps, absolute jumps, etc.) and the assembler picks the best one. As another example, almost all of the vector instructions have an encoding with a VEX prefix (an AVX encoding) as well as the older SSE encoding. If you mix the VEX and SSE encoded instructions, there can be a big slowdown, so an assembler will give you VEX encodings if you have AVX-only instructions in the stream, and default to SSE encodings if you don't (they are often smaller). Some instructions, like LEAs and ADDs, have several different encoding options corresponding to different operand orderings, and an assembler will pick the best one - some of these encodings will force an extra SIB byte when you use R12 as an operand, for example. This is kind of assembler-specific in terms of how smart it is. I'm not sure that the dumber assemblers do this for you.

littlestymaar 4y ago

> Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstraction, it would be an interface. Assembly gives you a nice sequential list of instructions, completely hiding pipelining, speculative execution, and all the magic that modern (since the 90s at least) CPU do to do the job fast. And as the Spectre family of CPU vulnerabilities, these abstractions are in fact more leaky than most people assume.

trashtester 4y ago
And cache management, thread switching optimization/prioritization, and so on. If a CPU were to ONLY do the instructions that were written in the assembly code, the code could be maybe 5-10 times slower when using cached memory and 100x slower if accessing RAM constantly. And this is part of the reason why it's hard to write assembly that is faster than a well optimized C/C++ program. The C compiler "knows" (to some extent) what the machine code leads to at the hardware level, and will often create machine code that is more liklely to allow the CPU to reap all such advantages in a way many assembly programmers wouldn't know about or think of.