flat assembler
Message board for the users of flat assembler.

Index > Main > operand size not specified

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji

hi, Wink
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)- Image
Post 04 Mar 2010, 21:57
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
What should happen here?
Code:
mov [esi],-1    
Post 04 Mar 2010, 22:10
View user's profile Send private message Visit poster's website Reply with quote
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)- Image
Post 04 Mar 2010, 22:18
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
What should happen here?
Code:
mov [esi],valueXYZ-constantABC    
Post 04 Mar 2010, 22:22
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
What about here?
Code:
use64
mov [esi],0x0a0d0a0d    
Post 04 Mar 2010, 22:23
View user's profile Send private message Visit poster's website Reply with quote
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)- Image
Post 04 Mar 2010, 22:30
View user's profile Send private message Send e-mail Reply with quote
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)- Image
Post 04 Mar 2010, 22:32
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
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
Post 04 Mar 2010, 22:34
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
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)
Post 04 Mar 2010, 22:34
View user's profile Send private message Reply with quote
zhak



Joined: 12 Apr 2005
Posts: 490
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
Post 04 Mar 2010, 22:35
View user's profile Send private message Reply with quote
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)- Image
Post 04 Mar 2010, 22:36
View user's profile Send private message Send e-mail Reply with quote
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)- Image


Last edited by ouadji on 04 Mar 2010, 23:05; edited 1 time in total
Post 04 Mar 2010, 22:44
View user's profile Send private message Send e-mail Reply with quote
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)- Image
Post 04 Mar 2010, 22:51
View user's profile Send private message Send e-mail Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
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
Post 05 Mar 2010, 07:17
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
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.
Post 05 Mar 2010, 09:05
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4238
Location: 2018
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
    
Post 05 Mar 2010, 09:29
View user's profile Send private message Visit poster's website Reply with quote
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)- Image
Post 05 Mar 2010, 09:40
View user's profile Send private message Send e-mail Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
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".
Post 05 Mar 2010, 15:20
View user's profile Send private message Reply with quote
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.
Post 05 Mar 2010, 17:47
View user's profile Send private message Reply with quote
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.
Post 05 Mar 2010, 18:34
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
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


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.