Hello.

Here is short piece of code, which compiles Ok, but might be considered as a bug: Fasm emits the 66h prefix, so JMP instruction with E9h opcode has a word-sized relative displacement. This is allright, of cource. When CPU executes such command, the ESP register becomes 00001004h (this is right as well).
The problem is: the @@ label has addres equal to 00401004h. May be it would be better to indicate an error in such situation? Some compile-time check might be done to be sure the jump address fits the 0000XXXXh limit. This should also help when one really want to use JMP with 66 E9 opcode to 0000XXXXh address from some 'out of range' address.

Regards.

This happens because in case of jump the size operator applies not to address itself, but to the relative address, since immediate in jumps is the relative offset. In this case the relative offset is both absolute value and fits in the 16 bits, therefore fasm doesn't show any error. Well, you may be right that this can be considered a bit strange, but it actually follows some logic - if size operator was interpreted as applying to address instead, the "jmp byte" wouldn't be accepted by fasm, too.

I see fasm does its job right. I'd rather say it's a CPU bug , beacuse such relative jump (or call) modifies EIP far away from -8000h/+7FFF range. I never thinked about such thing as a problem before this topic. May be when 'format pe' (or similar) option is set some warning (or error, however both of them may violate fasm philosophy) should appear for every 'jmp/call word' instruction? Anyway 0-FFFF rande isn't addressable under windos.

Added: Oh, no, this shouldn't stop compilation - I imagine some nice anti-debugging trick wiht SEH which can be easily implemented with this feature