4 ms·

It's great experience, but it's also slow as the compier must save the entire function state before your assembly block and cannot make any assumptions about w

It's great experience, but it's also slow as the compier must save the entire function state before your assembly block and cannot make any assumptions about what you do inside. This is acceptable if you see the point of inline assembly in writing long code sections, but that's not what inine assembly is meant to solve. If you want to write long sections of assembly code, just put the whole thing into an assembly source file and link it into your binary. gcc-style inline assembly on the other hand is designed to solve the problem of augmenting code generation with individual instructions the compiler doesn't know about. Correctly used, gcc-style asm statements typically only hold one or two instructions that are then integrated into a complex function with little to no overhead. And for this usage, the syntax and model provided by gcc is perfectly fine. It only fails if you misuse it for writing long chunks of assembly code, something for which you should have used an assembly file in the first place.

pjmlp 2y ago
> It's great experience, but it's also slow as the compier must save the entire function state before your assembly block and cannot make any assumptions about what you do inside. That is why there are function attributes and #pragmas to control what the compiler is supposed to do. Compilers that don't follow the brainded execution model of UNIX, with hard separation between compiler and Assembler phases, as separate processes comunicating via pipes, are a bit more knowledgeable of what those Assembly instructions are actually doing. Not only that, they are able to provide proper error messages when the opcodes are badly used.
- cesarb 2y ago
  > [...] are a bit more knowledgeable of what those Assembly instructions are actually doing. Not only that, they are able to provide proper error messages when the opcodes are badly used. That's only possible if the compiler knows all assembly instructions being used. But the whole point of GCC-style inline assembly is to be able to use assembly instructions the compiler doesn't know about (for instance, because they're new instructions which didn't exist when the compiler was released), with the same performance as the ones the compiler does know about. In many cases, even the assembler doesn't know about the new instruction, and you have to specify it using .byte directives or similar (though the Unix compiler model, with proper separation between the compiler and the assembler, also allows you to use a newer assembler without having to change your compiler).
  - pjmlp 2y ago
    Again, this kind of arguments gets tiring, compilers get upgrades.
    - leni536 2y ago
      And GCC/clang do get intrinsics that are nicer to use than inline asm, often with more optimization available to them as well. If the compiler does know about a specific instruction, then it's better to just provide the intrinsic than try to infer it from some inline asm string.
      - AshamedCaptain 2y ago
        One of the benefits of gcc's powerful inline asm support is that it allows you to write new intrinsics. This is almost impossible in most other compilers, as they will do crazy things such as flushing out all registers before each asm block. Very useful for low level work.
        leni536 2y ago
        > it allows you to write new intrinsics I admit that it gets very close, however I think compiler provided intrinsics can be and are optimized more than ones that are implemented with inline asm, as the compiler knows about the semantics of the instruction for such an intrinsic, and not much about an inline asm one, apart from inputs/outputs/clobbers. Having said that I agree that inline asm is very useful for instructions that the compiler does not know about.
    - secondcoming 2y ago
      That's great if you're not locked down to a particular compiler version
- AshamedCaptain 2y ago
  > That is why there are function attributes and #pragmas to control what the compiler is supposed to do. Which basically reinvent gcc's syntax to set input/output/modified registers, only worse. No thank you. The compiler you are most likely thinking off still does not allow to set multiple output values from an inline asm block, for example. Something the gcc/clang syntax has no problems with. These details all make the "ffi"/interface between the C world and your inline asm slower than it could be.
  - pjmlp 2y ago
    No thank you, to pasting strings.
    - AshamedCaptain 2y ago
      But yes to pragmas with register lists ? Be serious.

pjmlp 2y ago

> It's great experience, but it's also slow as the compier must save the entire function state before your assembly block and cannot make any assumptions about what you do inside. That is why there are function attributes and #pragmas to control what the compiler is supposed to do. Compilers that don't follow the brainded execution model of UNIX, with hard separation between compiler and Assembler phases, as separate processes comunicating via pipes, are a bit more knowledgeable of what those Assembly instructions are actually doing. Not only that, they are able to provide proper error messages when the opcodes are badly used.

cesarb 2y ago
> [...] are a bit more knowledgeable of what those Assembly instructions are actually doing. Not only that, they are able to provide proper error messages when the opcodes are badly used. That's only possible if the compiler knows all assembly instructions being used. But the whole point of GCC-style inline assembly is to be able to use assembly instructions the compiler doesn't know about (for instance, because they're new instructions which didn't exist when the compiler was released), with the same performance as the ones the compiler does know about. In many cases, even the assembler doesn't know about the new instruction, and you have to specify it using .byte directives or similar (though the Unix compiler model, with proper separation between the compiler and the assembler, also allows you to use a newer assembler without having to change your compiler).
- pjmlp 2y ago
  Again, this kind of arguments gets tiring, compilers get upgrades.
  - leni536 2y ago
    And GCC/clang do get intrinsics that are nicer to use than inline asm, often with more optimization available to them as well. If the compiler does know about a specific instruction, then it's better to just provide the intrinsic than try to infer it from some inline asm string.
    - AshamedCaptain 2y ago
      One of the benefits of gcc's powerful inline asm support is that it allows you to write new intrinsics. This is almost impossible in most other compilers, as they will do crazy things such as flushing out all registers before each asm block. Very useful for low level work.
      - leni536 2y ago
        > it allows you to write new intrinsics I admit that it gets very close, however I think compiler provided intrinsics can be and are optimized more than ones that are implemented with inline asm, as the compiler knows about the semantics of the instruction for such an intrinsic, and not much about an inline asm one, apart from inputs/outputs/clobbers. Having said that I agree that inline asm is very useful for instructions that the compiler does not know about.
  - secondcoming 2y ago
    That's great if you're not locked down to a particular compiler version
AshamedCaptain 2y ago
> That is why there are function attributes and #pragmas to control what the compiler is supposed to do. Which basically reinvent gcc's syntax to set input/output/modified registers, only worse. No thank you. The compiler you are most likely thinking off still does not allow to set multiple output values from an inline asm block, for example. Something the gcc/clang syntax has no problems with. These details all make the "ffi"/interface between the C world and your inline asm slower than it could be.
- pjmlp 2y ago
  No thank you, to pasting strings.
  - AshamedCaptain 2y ago
    But yes to pragmas with register lists ? Be serious.