If optimizing compilers are so good, why are there no optimizing assemblers?

An optimizing compiler IS an optimizing assembler. C is converted to assembly, which is then optimized.
Or are you talking about a hyperoptimizer? Those already exist as well.

>>105724552
>An optimizing compiler IS an optimizing assembler.
No it is not.
>C is converted to assembly
No, it's converted to an IR, which is then converted to machine code. It never touches an assembly language.
Assembly isn't the same thing as machine code, you know. You only make the mistake because there are no transformations applied to an assembly language other than choosing the shortest encoding for an instruction. It's not even a real 1:1 mapping because of that.

Why doesn't nasm rewrite my subroutines, erase unused code paths and stores, perform tail-call optimization, optimize my register usage, etc.?
gcc can track things like unaliased pointers and perform code transformations that erases huge chunks of code and makes it go faster. Why can't assemblers do that?

>>105723937 (OP)
the CPU is an optimizing assembler

>>105724805
How do I write assembly code to help the CPU's optimizer as much as possible?

>>105724862
https://www.agner.org/optimize
check out 2, 3, 4

>>105724795
>>C is converted to assembly
>No, it's converted to an IR, which is then converted to machine code. It never touches an assembly language.
It is definitely converted into assembly. Are you an AI? You say things that are blatantly wrong yet are confident about it.

>Why doesn't nasm rewrite my subroutines, erase unused code paths and stores, perform tail-call optimization, optimize my register usage, etc.?
Because it is an assembler and not a hyperoptimizer. If you want to optimize parts of your code, use a hyperoptimizer. Or if you want to optimize ALL of your code, then don't write assembly at all but C or Rust.

>>105724915
Interesting. What if i want it to be portable across multiple generations of cpu?

>>105725283
general principles like avoiding unnecessary branching and (non-linear) memory access will continue to apply for the foreseeable future

>>105723937 (OP)
assembly is a direct representation of the cpus instructions, hence there is nothing to optimize, you are telling the cpu exactly what to do.

>>105724795
gnu as was literally invented for gcc compilation of c. There was one compiler that uses to directly compile to.machine code (vcc?) but all the others do asm.first and rely on a separate assembler.

>>105725824
not even remotely

>>105725254
>Or if you want to optimize ALL of your code, then don't write assembly at all but C or Rust.
Unless you're actually serious about it, when you write assembly anyway.
An old boss of mine used to be that serious, and was very good at it. I never bother, as I prefer to make my code more robust.

>>105726456
frankly I've always had an easier time writing and debugging x86_64 assembly code compared to C in terms of robustness. It's also just as portable as C in most real life cases since only x86_64 matters (or mattered thanks macos) but that argument has more validity in my mind.

>>105726436
yes it is, it generally maps 1:1 with each instruction the cpu has.

>>105724795
We’ve had peephole optimizers since 1970s and GCC has some flag for it too https://en.wikipedia.org/wiki/Peephole_optimization
But more complex optimizations don’t make any sense for asm. If you’re hand writing assembly then you must want to have precise control over the generated machine code, else why do it? It’s really only useful for cases like crypto (preventing timing attacks) weird high perf edge cases (ffmpeg) kernel bootstrap (just a few instructions that do some set up then jump to the rest of your code written in C) and finally educational purposes. Not one of these cases benefits from optimizations, in fact that’s precisely what we want to avoid, that’s why we’re writing asm in the first place.

>>105726539
You are a 0 IQ cretin

>>105724552
>An optimizing compiler IS an optimizing assembler. C is converted to assembly, which is then optimized.
You don't need C to have a compiler. There are compilers for Lisp, Pascal, Fortran, COBOL, BASIC, Haskell, ML, and a lot of other languages. Also it is not an optimizing assembler because it doesn't optimize assembly that you write, it optimizes the high-level language. Compilers do not always produce assembly either, a lot of them create the machine code directly as binary.

>>105726565
then you must be a -50 iq mongoloid

>>105726617
I accept your surrender. Next time, use google before embarassing yourself.

>>105723937 (OP)
>why are there no optimizing assemblers
with assembly you control what instructions are used and the sequence of instructions, so how exactly is an assembler supposed to optimize without rewriting your code?

>>105726632
you didn't say a single thing to support your argument.

and if you are somekind of mega tard thinking that the cpu having a OoE and a decoder makes this untrue, then please commit sudoku.

>>105726675
>you didn't say a single thing to support that 1+1=2
Meds, now.

>>105724552
>>105725254
Umm ackshually, nitpick, it’s a superoptimizer not a “hyperoptimizer,” there’s no such thing as the latter.

compiled languages have constraints and the compiler can optimize within those constraints, an assembler has no idea wtf you're trying to do and that retarded sequence of instructions you gave it might be intentional for all it knows

there are, kind of
MIPS assemblers will reorder instructions to make use of the branch delay slot
some assemblers have pseudo instructions that expand into multiple normal instructions
x86 has multiple ways of encoding the same instruction and assemblers will pick generate the smallest encoding

>>105725283
>What if i want it to be portable across multiple generations of cpu?
Write it in C, dummy. Extremely simple C is a better assembly than assembly, because the compiler understands uop instruction scheduling and how to keep execution units busy much better than humans can.

>>105728845
C is the worst language you can pick and it's not a replacement for assembly at all, unless it's the kind of program you can write in any language.