Rules for immediate operand sizes

Index > Main > Rules for immediate operand sizes

Goto page Previous 1, 2

Author

Thread

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 29 Jan 2010, 00:08

Plue wrote:

Because this becomes a problem when you move into a 32-bit register, as the value is then sign extended.

Are you talking about x86?

Code:

movsx <-- sign-extend
movzx <-- zero-extend

two different instructions, depending on what you, aka the programmer/user, want. Why should FASM decide for you?

Plue wrote:

You see, there are two ways to assemble "add ecx, 155": one is to treat 155 as a byte and the other way is to treat it as a dword. Treating it as a byte gives a smaller code. But if you treat 233 as a byte, then the value will be wrong when it is sign extended.

What? You can't add a byte to a 32-bit value, it's wrong size... if you mean the opcodes who sign-extend an 8-bit value into 32-bit, that's completely transparent to the programmer/user.

But I agree about enter and ret, because those instructions in the CPU, not the programmer, work unsigned. Mov doesn't work either signed nor unsigned... it's up to the user.

_________________
Previously known as The_Grey_Beast

29 Jan 2010, 00:08

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20519
Location: In your JS exploiting you and your system

revolution 29 Jan 2010, 06:49

LocoDelAssembly wrote:

Quote:
imm16 — An immediate word value used for instructions whose operand-size attribute is 16 bits. This is a number between –32,768 and +32,767 inclusive.

As is common with these types of things, and LocoDelAssembly correctly shows us, the manuals don't give the whole picture. One should never rely upon manuals as being perfectly accurate for everything. They are written by humans and thus prone to errors, inconsistencies and/or omissions. Fortunately we have a way around this problem with the manuals, we can test it for ourselves.

LocoDelAssembly wrote:

So, would you expect that "RET -4" subtracts four from ESP in 32-bit mode instead of adding 65532?

Yes indeed, point proved beyond doubt. The manuals don't give the whole picture. The manuals are a starting point to give us an overview, but the tiny little details will slip between the cracks.

29 Jan 2010, 06:49

hopcode

Joined: 04 Mar 2008
Posts: 563
Location: Germany

hopcode 29 Jan 2010, 10:52

You are missing the whole point
(and this is my last post on this blogging thread):

if you write:
RET -4 fasm compiles good,but that is probably an user coding error
if fasm receives RET -4 from a frontend, fasm compiles it good,but that is probably a frontend coding error
if you find C2FCFF from fasm output, that is probably an user/frontend coding error
All these encodings are allowed on intel cpu and by fasm.

other instruction other output, and we could discuss for two years
without finding/proposing a solution. For example BT and the clear statement on Intel docs:

Quote:

Some assemblers support immediate bit offsets larger than 31 by using the immediate
bit offset field in combination with the displacement field of the memory
operand. In this case, the low-order 3 or 5 bits (3 for 16-bit operands, 5 for 32-bit
operands) of the immediate bit offset are stored in the immediate bit offset field, and
the high-order bits are shifted and combined with the byte displacement in the
addressing mode by the assembler. The processor will ignore the high order bits if
they are not zero.

Can you read the last sentence ?
Do you understand the point ?
There is a reason because fasm/processor allows you to encode

Code:

MOV CL,233 ;or 
RET -4

It is to say, coehrence is the matter.
I have myself asked for the MONITOR instruction not long ago. What fasm accepts in the source is the double form implicit/explicit.
It is to say, the matter is not about coding errors. It is about
avoiding to use of a new directive in the source code
(like for example could be a "strict") just alike for
the MONITOR instruction:

2 uses 1 encoding
and so for the MOV CL,233, RET/ENTER etc.

Or should we state that because of the 2 uses fasm doesnt accomplish the WYSIWYG feature ?

Or pehraps instead of writing
MOV CL,233
you would prefer
MOV CL,-23
Exclamation

Bye Bye
hopcode
.
.
.

29 Jan 2010, 10:52

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20519
Location: In your JS exploiting you and your system

revolution 29 Jan 2010, 11:03

hopcode: Just because the Intel manual says imm8 is signed does not mean that "mov cl,233" should be wrong. The manual is not god or perfect or anything like that. Bytes can be interpreted as signed or unsigned, this is normal. fasm allows both signed and unsigned values to be entered.

What happens here?

Code:

mov cl,127
add cl,1 ;OMG, the CPU will explode, 128 cannot be encoded!!!!!!!

29 Jan 2010, 11:03

Plue

Joined: 15 Dec 2005
Posts: 151

Plue 29 Jan 2010, 11:49

Borsuc wrote:

Plue wrote:
You see, there are two ways to assemble "add ecx, 155": one is to treat 155 as a byte and the other way is to treat it as a dword. Treating it as a byte gives a smaller code. But if you treat 233 as a byte, then the value will be wrong when it is sign extended.
What? You can't add a byte to a 32-bit value, it's wrong size... if you mean the opcodes who sign-extend an 8-bit value into 32-bit, that's completely transparent to the programmer/user.

I know that's transparent to the user of an assembler, but I AM WRITING AN ASSEMBLER (did you read the first post?), and IT'S NOT TRANSPARENT TO THE ASSEMBLER. So I was asking how to handle this, and it seems that the answer is that I have to know this per opcode, as there is no general rule.

_________________
Roses are red
Violets are blue
Some poems rhyme
And some don't.

29 Jan 2010, 11:49

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 29 Jan 2010, 19:25

@Plue, sorry I probably skipped it. Sad

29 Jan 2010, 19:25

Goto page Previous 1, 2

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum