2 ms·

> As a practical matter, few people have the capability to mentally simulate the pipeline to determine whether slow LEA is going to have an impact or not That'

by acqq 7y ago

> As a practical matter, few people have the capability to mentally simulate the pipeline to determine whether slow LEA is going to have an impact or not That's why the people should not do it most of the time, that's why we have compilers. And I claim that a compiler programmed in absolutes as advised by the article "just don't use EBP with LEA" would produce poor code. And that much is easy to follow even by humans.

BeeOnRope 7y ago
If you were writing a compiler, you'd just use the correct rule (and you'd make sure you assembler chose ebp as the index not the base in cases like [ebp + edx]), of course. I'm wasn't even arguing for the use of the over-broad rule in the part you quoted: I was actually arguing for the use of the full rule but without worrying too much about the caveat that even using slow lea might be just as fast (or faster, due to non-monotonic effects).
- acqq 7y ago
  > you'd make sure you assembler chose ebp as the index not the base in cases like [ebp + edx]), of course. There's nothing that prevents existing assemblers to already do this -- I haven't checked them though, since I used my own -- I use the term "compiler" as everything together up to the parts that produce the actual binary codes. I know that e.g. gcc makes (or, at least, made) an explicit separation producing the assembly in the source form. But it still would be plausible that it's already implemented in such assemblers -- which would make the userbinator's argument here even less relevant.
  - BeeOnRope 7y ago
    As far as I know at least some assemblers do this - certainly nasm, for example, makes all kinds of similar optimizations to the encoding, and I expect it to get this one right. It's kind of too little, too late though: you want the higher level compiler to be avoiding rbp/r13 in scenarios where this could occur and the assembler couldn't fix it. I don't think compilers do this, though.

by acqq 7y ago

BeeOnRope 7y ago

If you were writing a compiler, you'd just use the correct rule (and you'd make sure you assembler chose ebp as the index not the base in cases like [ebp + edx]), of course. I'm wasn't even arguing for the use of the over-broad rule in the part you quoted: I was actually arguing for the use of the full rule but without worrying too much about the caveat that even using slow lea might be just as fast (or faster, due to non-monotonic effects).

acqq 7y ago
> you'd make sure you assembler chose ebp as the index not the base in cases like [ebp + edx]), of course. There's nothing that prevents existing assemblers to already do this -- I haven't checked them though, since I used my own -- I use the term "compiler" as everything together up to the parts that produce the actual binary codes. I know that e.g. gcc makes (or, at least, made) an explicit separation producing the assembly in the source form. But it still would be plausible that it's already implemented in such assemblers -- which would make the userbinator's argument here even less relevant.
- BeeOnRope 7y ago
  As far as I know at least some assemblers do this - certainly nasm, for example, makes all kinds of similar optimizations to the encoding, and I expect it to get this one right. It's kind of too little, too late though: you want the higher level compiler to be avoiding rbp/r13 in scenarios where this could occur and the assembler couldn't fix it. I don't think compilers do this, though.