That compiles with latest FASM. Shouldn't it be disallowed? In any case of course FASM only allows numbers that are encodable as imm8 but it is somewhat odd to accept -1 as 255 in the context of those instructions (and any other that negative values makes no sense)

I made this tests after looking into a recent thread hopcode participated in talking about ENTER instruction.

PS: I'm half convinced of what I'm saying above so for that reason I'm not flagging it as a bug.

And surely there are more instructions. What do you think, it is OK to allow that?

No. I think it should be changed. Often these constants can become obscured by macros and symbolic names so the programmer can find it hard to know that negative values are being assembled without any error being generated.

Isn't it nitpicking. I've always wondered why is there SUB-instruction when you can perfectly and legally exchange it with negative ADD-instruction, but I don't consider it evil.
add eax,-1 is perfectly okay too.

then you have to wonder what algorithmic importance does an xor eax,-4 have? I am opposed to the idea of having FASM decide how we should code. If one's worried about negative horror then its the job of the macros.
if imm8<0 then display "Warning: "#imm8#" is not a supported value" etc.

Madis731: "SUB eax,ebx", How to do with ADD?

"add eax,-1" is okay. Since it is a 2's complement adder.

But "retn -4" does not use a 2's complement adder internally. The CPU will do the "wrong" thing if you are expecting "ret / add esp,-4" then you won't get it.

Even Ollydbg displays "retn 0xFFFC". '-4' is not really correct. Although not a serious problem I think it is still something that needs looking at.

- add eax,-1 is not the problem, no fasm change.
- int -101 not necessary, even if int -3 is not int 3, it is to say, there is no useful internal operation over the imm8 in the int istruction; anyway, because it is a imm8 a fasm change could inhibit users thinking negative (int -3 instead of int 0FDh) to avoid undesiderable results. in fact in this way, they could only use absolute imm8 values.
- retn -4 no fasm change, it is user responsability avoid errors
- enter 4,-128 no fasm change,it is not necessary,
also, my opinion, if useful is for those instructions no change

I think he was talking about SUB with an immediate. That is worthless and wastes encoding space.

No, not worthless, in x86 the flags are set differently.

@revolution - yes
and
@Borsuc - yes and no


I'm sorry, but I didn't think about immediates - though I should have - I thought in general SUB is a waste of encoding space, but... well seb eax,ebx is great to have.

What I was actually trying to prove that sometimes add eax,-1 is more obfuscated than sub eax,1. I cannot prove, however, that ret or int will have uses in some code.

Therefore I shall argue no more

Which flags? The carry flag?

Yes, and also the overflow flag.

Overflow flag will be different only when (for 32-bit operands) 0x80000000 is added/subtracted (because -0x80000000==0x80000000 ). And don't forget an AF (albeit nobody cares about it).

Overflow flag will be different for other values also.

0x80000000 + 0xffffffff ---> carry, no overflow
0x80000000 - 0x00000001 ---> overflow, no carry

revolution,

0x80000000+0xFFFFFFFF… No overflow, really? -2**31+(-1)==-(2**31+1), which does not fit in signed 32-bit.

Yep, this crash:

forget about my overflow example.

mmh... i dont know if i mistake but
it seems to me as we are playing in a Buñuel movie (one of my preferite
directors with Tarkowskij and Fassbinder), exactly
"El ángel exterminador"
http://en.wikipedia.org/wiki/The_Exterminating_Angel_%28film%29
by the fact that we discuss
round and round on fasm at a "bourgeois" level without safe exiting,
neglecting (one of) the most important concepts of fasm, it is to say, the
10 or more years of sssO experience of fasm, in few words, the WYSIWYG feature,
that makes fasm so different from other fuzzy-funky-thingy-kopflos-zusamenfassungen compilers.
For that feature, one learn in less time (this is what happens to me) and
outputs automatically aware less "tricks" as compared to other compilers output.
Why obfuscate that capability ?

Cheers,
hopcode

(is that provoking ?)

If the processor operates with an unsigned number then negative numbers are incorrect. Since FASM correctly errors in some cases and has the precision to detect a number out of bounds, I assume the implementation is just incomplete rather than having this behavior as a feature. Hiding coding errors is never desirable.