operand size not specified

Index > Main > operand size not specified

Goto page 1, 2 Next

Author

Thread

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji

hi,

Code:

format MS COFF
...
mov [esi],0A0D0A0Dh

"operand size not specified"

Why should I specify operand size, since I give a 32-bit operand ?
(with only "0A0Dh", I understand ... but here, with "0A0D0A0D", why ?)
There is in this case no ambiguity possible.
thank you.

_________________
I am not young enough to know everything (Oscar Wilde)-

04 Mar 2010, 21:57

revolution
When all else fails, read the source

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

revolution

What should happen here?

Code:

mov [esi],-1

04 Mar 2010, 22:10

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji

yes revolution, in this case (-1), there is a ambiguity, i understand ...( byte, word, dword ?)
In this case, i'm agree with you. But with operand "0A0D0A0Dh", there is no ambiguity.
The question about operand size has no meaning

An operand whose size exceeds the word should automatically be considered a double word.
There is anyway no alternative.

_________________
I am not young enough to know everything (Oscar Wilde)-

04 Mar 2010, 22:18

revolution
When all else fails, read the source

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

revolution

What should happen here?

Code:

mov [esi],valueXYZ-constantABC

04 Mar 2010, 22:22

revolution
When all else fails, read the source

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

revolution

What about here?

Code:

use64
mov [esi],0x0a0d0a0d

04 Mar 2010, 22:23

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji

"valueXYZ-constantABC"

yes revolution,
but here too there is ambiguity about the size of the result.
In my case, there is no ambiguity.
When there is no ambiguity, and the size of the operand is explicit and exceeds the word,
FASM should consider directly that this is a double word.
yes, it's a littel bit a cosmetic problem Wink

...
but this is illogical and unnecessary.

_________________
I am not young enough to know everything (Oscar Wilde)-

04 Mar 2010, 22:30

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji

yes,
with "USE64" there is a ambiguity.
In this case, i'm agree with you too.
But in my case, there is no ambiguity.

_________________
I am not young enough to know everything (Oscar Wilde)-

04 Mar 2010, 22:32

revolution
When all else fails, read the source

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

revolution

It is not cosmetic, it allows for very sloppy programming. fasm should not have to guess the size. What if I want a word size but accidentally put 0xfffff? I see no error from fasm but my program crashes for unknown reasons!

Last edited by revolution on 04 Mar 2010, 22:35; edited 1 time in total

04 Mar 2010, 22:34

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly

Code:

mov [esi], SOME_CONFIGURABLE_EQUATE ; Keep compiling until someone decides to use a constant with "size ambiguity"

(Note, the assembler and parser stages can't know where the literal came from so it can't make an special case when the constant is typed straight)

04 Mar 2010, 22:34

zhak

Joined: 12 Apr 2005
Posts: 501
Location: Belarus

zhak

oh, come on, ouadji. what is all about? are you too lazy to put 5 letters "dword" in front of [esi]?

Last edited by zhak on 04 Mar 2010, 22:36; edited 1 time in total

04 Mar 2010, 22:35

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji

Code:

mov [esi],eax
mov [esi],0A0D0A0Dh

in both cases, there is no ambiguity.

_________________
I am not young enough to know everything (Oscar Wilde)-

04 Mar 2010, 22:36

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji

Quote:

Note, the assembler and parser stages can't know where the literal came from so it can't make an special case when the constant is typed straight

thank you revolution.
with this answer, I understand now.

Quote:

are you too lazy to put 5 letters "dword" in front of [esi]?

sorry, ridiculous reply that deserves no interest.

_________________
I am not young enough to know everything (Oscar Wilde)-

Last edited by ouadji on 04 Mar 2010, 23:05; edited 1 time in total

04 Mar 2010, 22:44

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji

Quote:

It is not cosmetic, it allows for very sloppy programming. fasm should not have to guess the size. What if I want a word size but accidentally put 0xfffff? I see no error from fasm but my program crashes for unknown reasons!

indeed, it's correct, thank you.

_________________
I am not young enough to know everything (Oscar Wilde)-

04 Mar 2010, 22:51

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen

ouadji wrote:

yes,
with "USE64" there is a ambiguity.
In this case, i'm agree with you too.
But in my case, there is no ambiguity.

With use64 there is no ambiguity as well, you can't move 64-bit immediate value to memory in any case.

EDIT:
Not quite true, you can't move values 80000000-FFFFFFFF to 64-bit memory operand. You can move 0-7FFFFFFF.

Last edited by MazeGen on 06 Mar 2010, 12:11; edited 1 time in total

05 Mar 2010, 07:17

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8000
Location: Kraków, Poland

Tomasz Grysztar

LocoDelAssembly wrote:

(Note, the assembler and parser stages can't know where the literal came from so it can't make an special case when the constant is typed straight)

Do you mean values defined with EQU here? Since for numerical values you should use the = directive anyway, and in such case assembler is pretty much capable of deciding, whether it was the literal or not.
But this still doesn't make this idea any good. I don't want people reporting bugs that "mov [esi],65536" assembles fine, but after they decrement value, it suddenly stops assembling.

05 Mar 2010, 09:05

edfed

Joined: 20 Feb 2006
Posts: 4267
Location: Now

edfed

and please note that fasm is a compiler that generate a flat image of the source.
then, operand size should be specified because there are at least 3 possible sizes.

it can be a problem sometimes, but ones you are used to this problem, it is no longer a problem.

Code:

mov dword[esi+eax*4],0

05 Mar 2010, 09:29

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji

Quote:

from Tomasz Grysztar :

I don't want people reporting bugs that "mov [esi],65536" assembles fine,
but after they decrement value, it suddenly stops assembling

indeed, this is right too !

_________________
I am not young enough to know everything (Oscar Wilde)-

05 Mar 2010, 09:40

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly

Tomasz Grysztar wrote:

Do you mean values defined with EQU here?

Yes, that meant that it can't know whether it came from an equate or an in-place literal. I used that example to remove the chances of anyone saying "but fasm could know it by keeping track of how the variable was assigned".

05 Mar 2010, 15:20

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

This problem looks similar to signed vs. unsigned contradiction:

Code:

a = 1 shl 63 - 1; 0x7FFF'FFFF'FFFF'FFFF
b = a+1
if b>a
  display "b>a", 13, 10
else
  display "b<=a", 13, 10
end if
if b-a>0
  display "b-a>0", 13, 10
else
  display "b-a<=0", 13, 10
end if

Not a big surprise for those who are familiar with FASM internals, though.

05 Mar 2010, 17:47

edemko

Joined: 18 Jul 2009
Posts: 549

edemko

Never thought how fasm does number comparison.., it is signed.
b-a = 10b - 01b = 01b which is unsigned.
All is fine.

05 Mar 2010, 18:34

Goto page 1, 2 Next

< 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