Quick assembly question

I'm having to convert an inline assembly block from MSVC to MinGW (it cannot be written in C++, as it passes a runtime-determined number of arguments to function calls) - I've got it all converted, except that there is an error that I can't resolve. I have absolutely no assembly experience, and apparently I'm not good at Googling because I can't find anything relevant to my error.

I have this assembly line:

fstp Result;

Where Result is an int declared before the assembly block. The error I am getting is:
AppData\Local\Temp\cc7Qc9sw.s: Assembler messages:
AppData\Local\Temp\cc7Qc9sw.s:4638: Error: ambiguous operand size for `fstp'
All I know is that the variable Result is supposed to take the value of a float, as if by a reinterpret_cast.
I don't know asm, but this is in a book I have
Professional Asembly Language by Richard Blum wrote:

The FSTP instruction also copies the ST0 FPU register value, but then pops it from the FPU register
stack. This shifts all of the FPU stack values up one place in the stack.
Don’t forget to add the data size character to the end of the FST and FSTP mnemonics to specify the
proper size of the resulting data value. In this example, the FSTPS instruction is used to create a singleprecision
floating-point value stored in 4 bytes (32 bits) of memory from the value in the ST0 FPU stack
position:


I guess try using fstps.
Last edited on
I get an error, no such instruction. :\
Last edited on
Try adding DWORD or another size operand in front of it, like so:

FTSP DWORD Result;
or

FTSP DWORD PTR Result;
Hope it helps.
The command is fstp, not ftsp, and when I try what you suggest it gives an error that 'Result' is junk after the command.
Sorry try:
FSTP DWORD PTR[Result];
or
FSTP DWORD [Result];
Although it is probably the former that would work.
I am assuming result holds a pointer to a memory address, if not then you are trying to copy a 32 bit float to a 32 bit int and that is not going to end well.
Yes, I am definitely trying to copy a 32-bit float to a 32-bit integer, it's required for API compatibility with a C SDK.
Yes, I am definitely trying to copy a 32-bit float to a 32-bit integer, it's required for API compatibility with a C SDK.

lol, I was just saying that because you said:
L B wrote:
I have absolutely no assembly experience

And thus if you have absolutely no experience, then it would be perfectly possible to do that.
So did it work or not?
I get the exact same error, "ambiguous operand size for fstp".
closed account (o1vk4iN6)
If you want to store it as integer wouldn't you want to use FIST / FISTP ?

Really hate how GCC over complicates asm, tho i guess for the better.
http://ideone.com/CxbjCT
Last edited on
Perhaps the answer and comments given here:
http://stackoverflow.com/a/8737323/1708463
will be helpful.
@xerzi that is not at all what is trying to be accomplished here.
@cire I don't see how that's relevant :\

Maybe I had better post the entire assembly I am trying to convert. This is the code that compiles under MSVC:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
	int * Parameters;
	int ParameterCount;

	void * Function = ::SDK->ExpressionFunctions[ID];

	//...code to load parameters...

	void * Extension = rdPtr->pExtension;

	int Result;
	int ExpressionType = ::SDK->ExpressionTypes[ID];

	__asm
	{
		pushad

		mov ecx, ParameterCount
		
		cmp ecx, 0
		je CallNow

		mov edx, Parameters

		mov ebx, ecx
		shl ebx, 2

		add edx, ebx
		sub edx, 4

	PushLoop:

		push [edx]
		sub edx, 4

		dec ecx

		cmp ecx, 0
		jne PushLoop

	CallNow:

		mov ecx, Extension
		call Function

		mov ecx, ExpressionType;

		cmp ecx, 1
		jne NotFloat

		fstp Result
		jmp End

	NotFloat:
		
		mov Result, eax
		
	End:

		popad
	}

	return Result;
To convert it to MinGW's inline assembly format, all I am doing is changing __asm to __asm__, changing the curly braces to parens, and placing all the instructions in quotes with semicolons after them. The code works correctly as-is in MSVC, but the fstp Result line will not compile under MinGW.
Last edited on
@cire I don't see how that's relevant :\

fst and fstp are the same, except that fstp pops ST0 from the stack.

The answer and comments I linked had the same error message you are getting which doesn't occur in regular gcc or MSVC, but does in mingw. The OP got his code to work with mingw by specifying size in the instruction (fstps for you) and using constraints (neither of which you appear to be doing.)

It seems relevant to me.
fstps is not a valid instruction, which is why I thought it was not relevant.
closed account (o1vk4iN6)
Can you also post your asm code for mingw ?
http://ideone.com/i2F2S0
First off, what does the following do:
void * Function = ::SDK->ExpressionFunctions[ID]; void * Extension = rdPtr->pExtension; int ExpressionType = ::SDK->ExpressionTypes[ID];

Secondly, the instruction fstp does the following AFAIK:
http://docs.oracle.com/cd/E19455-01/806-3773/instructionset-133/index.html
So it stores the floating point value at the top of the FPU stack somewhere, and then pops it off the stack, right?
Now in your example Result is declared as an int. Should it not be a float pointer or an actual float?
I am sorry if I am terribly misinterpreting what is happening, but I am just trying to help.
@xerzi https://github.com/LB--/windows-edif/blob/master/Lib/Edif.cpp#L711
-masm=intel

@Script Coder: Function is the address of the member function to be called, Extension is the this pointer. ExpressionType is either 0 (int), 1 (float), or 2 (char *). In the example it has to be an int because that is what is getting returned from the DLL back to the software, which interprets the return value as the correct type.
Last edited on
closed account (o1vk4iN6)
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#s5

If you want to access elements outside you have to specify them. As far as i know, unless there is a compiler setting that changes that. GCC at least uses AT&T syntax, you are using Intels unless you specify otherwise.
Topic archived. No new replies allowed.