3 ms·

yes, of course, but there are ways to reason about programs that are not expressible in assembly, so a purely assembly program is not able to reason about itsel

yes, of course, but there are ways to reason about programs that are not expressible in assembly, so a purely assembly program is not able to reason about itself in this way in order to optimize itself in the same way as a higher level program can. both domains can do things the other can't. and, again, the more complex a concept is, the more difficult it is to implement in assembly, due to the sheer volume of code. you can't argue with that.

P5fRxh5kUvp2th 4y ago
This is called moving the goalpost. You started talking about speed, now you're talking about "expressiveness", which is a wholly different thing. Stay on topic.
- boltzmann-brain 4y ago
  no, that's exactly what I was talking about in the first reply, i just reiterated it, because your reply wasn't taking any of that into account.
  - P5fRxh5kUvp2th 4y ago
    Then you went for a strawman because the discussion was about performance, not expressiveness.
    - boltzmann-brain 4y ago
      No, my original comment is about performance, and out of that follows the necessity for expressiveness. Compilers and runtimes can perform more powerful optimizations when they have more semantics available to them. Meanwhile assembly is just a bunch of homogenous gunk to optimizers. At least until decompilers get way smarter than even the best ones are right now. Even IDA / HexRays don't reason about code at a level high enough to propose safe optimizations that can rival such optimizations as runtimes and compilers can perform when dealing with semantically rich code.
      - flohofwoe 4y ago
        > ...Meanwhile assembly is just a bunch of homogenous gunk to optimizers I wouldn't expect an assembler try to apply any further optimizations to my assembly code, that would be indeed quite pointless. For any specific problem, a human writing assembly code will almost always be able to exploit weird loopholes in a specific CPU instruction set that a compiler for a high level general programming language won't be able to (unless we're going into the realm of superoptimization via brute-force trial-and-error where an optimizer may eventually arrive at the same tricks that an anarchist assembly programmer would do).

P5fRxh5kUvp2th 4y ago

This is called moving the goalpost. You started talking about speed, now you're talking about "expressiveness", which is a wholly different thing. Stay on topic.

boltzmann-brain 4y ago
no, that's exactly what I was talking about in the first reply, i just reiterated it, because your reply wasn't taking any of that into account.
- P5fRxh5kUvp2th 4y ago
  Then you went for a strawman because the discussion was about performance, not expressiveness.
  - boltzmann-brain 4y ago
    No, my original comment is about performance, and out of that follows the necessity for expressiveness. Compilers and runtimes can perform more powerful optimizations when they have more semantics available to them. Meanwhile assembly is just a bunch of homogenous gunk to optimizers. At least until decompilers get way smarter than even the best ones are right now. Even IDA / HexRays don't reason about code at a level high enough to propose safe optimizations that can rival such optimizations as runtimes and compilers can perform when dealing with semantically rich code.
    - flohofwoe 4y ago
      > ...Meanwhile assembly is just a bunch of homogenous gunk to optimizers I wouldn't expect an assembler try to apply any further optimizations to my assembly code, that would be indeed quite pointless. For any specific problem, a human writing assembly code will almost always be able to exploit weird loopholes in a specific CPU instruction set that a compiler for a high level general programming language won't be able to (unless we're going into the realm of superoptimization via brute-force trial-and-error where an optimizer may eventually arrive at the same tricks that an anarchist assembly programmer would do).