Hi *,

I need store result of floating point calculation (in my example arctan()) in memory pointed by some variable. See this code: var a: single; pa: PSingle;
asm
fild dy
fild dx
fpatan
fstp a
fwait

   end;
   pa^ := a;

It works, but is there any way how to store result directly to "pa^" in assembler ?
I have tried:
...
fpatan
fstp pa^ ... fstp (pa) ... but this does not compile ... I need store to memory location pointed by pa "variable"
fwait

   end;

Thanks
-Laco.

"LacaK" wrote

Hi *, I need store result of floating point calculation (in my example

arctan()) in memory pointed by some variable. See this code:

assembler ?

I have tried: ... fpatan fstp pa^ ... fstp (pa) ... but this does not compile ... I need

store to memory location pointed by pa "variable"

fwait end;

You need to retrieve the value of pa into a register and then store at that address. Something like this:

=== code begin ===
mov edx, pa
fstp [pa]
=== code end ===

Note 1: not tested
Note 2: you might want to check which register you can use for that Note 3: I hope you keep the global and the assembler function in the same unit, because inter-unit access to globals changes when dynamic packages are enabled for a target

Regards,
Sven

Thank you!
I have hoped, that there is some kind of direct usage. Because "fstp a" is compiled into:
fstps -0x24(%ebp) // address of local variable "a" on stack and "pa^ := a" into:
mov -0x4(%ebp),%eax
mov -0x40(%eax),%edx // pa
mov -0x24(%ebp),%eax // a
mov %eax,(%edx) // a -> pa^

so I hoped, that there is possibility to do it directly : fstps (-0x24(%ebp))
but seems that this construct (use address stored on address) is not supported by processors performance POV result is same, so my optimalisation does not bring much effect.
(and also make it portable from 32 to 64 bit brings problems as far as I expect, that "mov pa, edx" will not work as it should be on 64 bit "mov pa, rdx"
Thanks
-Laco.

Hi,

which can jump to an address stored at the address pointed by the reference operand, IIRC. But that's the exception. The x86 instruction set is not too orthogonal, it's full of "special" cases like that one.

But really fast CPUs usually don't like such constructs, because it has too many interdependencies and sub-instructions (like, address calculation has to be done multiple times), so it's hard decode, pair and to pipeline them. Yes, the encoding would be smaller, but less instructions doesn't directly mean faster execution on most modern processors.

Charlie