Hi all!
Tomasz, i have little suggestion - is it possible to make next jump excluded by FASM:



It is very simple example, but in case of macro constructs such situations require some additional compiler directives code to check, if it is jump to next instruction or not in order to remove unnecessary ones. Maybe it is better to use FASM compiler itself, as it knows after all compile passes what situations with jumps are?

Thanks and regards.

First: that would be way beyond the line of what the low-level assembler should optimize by itself. You should do that with macros, just like some other optimizations discussed on this board. Just overload the "jmp" instruction with a macro, it should work like a charm. And if slows down compilation too much for you, you can enable this macro only when making the final executable (for release).

Second: this kind of jump is sometimes needed, like when you enter processed mode. I cannot image how angry (and confused) some programmers would get when assembler did such optimization for them in such case.

Thank for your quick reply, Tomasz. I'll try to do it with assembler directives in my case.

I wrote a sed script / .BAT for this for checking my simple DOS programs (which can have this due to too many careless cut n' pastes). Of course, it wouldn't work on your macro use since "@f" and "@@" don't match. But it can be done. And I still say something like this internally to FASM is unlikely to bite more than 1% of users. (Of course, just make it optional via some directive: NOBLOAT or similar, heh.)

I was thinking about collecting all such macros into one "agressive optimization" macro package. You could just include it into your sources just to compile the final release.

Agree. FASM core shouldn't do things like drop jumps, replace MOV by XOR, CMP by TEST, ...

The thing core defenitely should do is apply short variant of instructions (implied sign extension if possible & need, short jumps, smart indirect addressing encoding/optimization) by default. That's enough /for the first time;)?/

Don't forget that TASM was part of the inspiration behind FASM, and it had normal MASM mode as well as an improved IDEAL mode. So, with that reasoning, there's no reason that FASM (in theory) couldn't support more, including a separate mode for more aggressive optimizations.

The jump issue could be handled by a warning, however. Maybe that's the best answer, add a diagnostics mode that returns more warnings than normal without actually changing anything.