Message board for the users of flat assembler.
> Main > Rules for immediate operand sizes
Goto page Previous 1, 2
Are you talking about x86?
Because this becomes a problem when you move into a 32-bit register, as the value is then sign extended.
two different instructions, depending on what you, aka the programmer/user, want. Why should FASM decide for you?
movsx <-- sign-extend movzx <-- zero-extend
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.
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.
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||
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.
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.
So, would you expect that "RET -4" subtracts four from ESP in 32-bit mode instead of adding 65532?
|29 Jan 2010, 06:49||
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:
Some assemblers support immediate bit offsets larger than 31 by using the immediate
Can you read the last sentence ?
Do you understand the point ?
There is a reason because fasm/processor allows you to encode
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
you would prefer
|29 Jan 2010, 10:52||
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?
mov cl,127 add cl,1 ;OMG, the CPU will explode, 128 cannot be encoded!!!!!!!
|29 Jan 2010, 11:03||
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||
@Plue, sorry I probably skipped it.
|29 Jan 2010, 19:25||
|Goto page Previous 1, 2
< Last Thread | Next Thread >
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.