fist(p)

Index > Main > fist(p)

Goto page 1, 2 Next

Author

Thread

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 30 Apr 2011, 21:07

Does FISTP write atomically if the memory target is not aligned on 64 bits boundary ?

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

30 Apr 2011, 21:07

revolution
When all else fails, read the source

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

revolution 01 May 2011, 01:33

No.

Unaligned memory writes are never guaranteed to be atomic, no matter what instruction you use for writing.

It is in the docs.

01 May 2011, 01:33

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 01 May 2011, 07:21

Quote:

it is in the docs

yes, i know that !
but,

clic

in this page:
this is what gave me a doubt!

Quote:

However, there is an even better way, if we use a trick:
void atomicWrite64(void* p, __int64 value)

__asm
{
mov edi, p
fild qword ptr [value]
fistp qword ptr [edi]
}

This code uses the FPU to write the value atomically.
....

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

01 May 2011, 07:21

revolution
When all else fails, read the source

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

revolution 01 May 2011, 09:35

ouadji wrote:

this is what gave me a doubt!

Serves you right for relying on a blog posting about C. Razz

BTW: Note that fild&fist combo is not guaranteed to keep all integers intact without rounding it!

01 May 2011, 09:35

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 01 May 2011, 15:49

Quote:

Note that fild&fist combo is not guaranteed to keep all integers intact without rounding it!

inside the Fpu, with 64 bits for the mantissa,
yes, an integer will never be rounded.
(not true with 64bits or 32 bits float, but with 80 bits, yes)

Code:

__asm
{
mov edi, p
fild qword ptr [value]
fistp qword ptr [edi]
}

where have you seen C ?

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

01 May 2011, 15:49

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 01 May 2011, 16:21

Intel System Programming Guide 3A wrote:

An x87 instruction or an SSE instructions that accesses data larger than a quadword
may be implemented using multiple memory accesses. If such an instruction stores
to memory, some of the accesses may complete (writing to memory) while another
causes the operation to fault for architectural reasons (e.g. due an page-table entry
that is marked “not present”). In this case, the effects of the completed accesses
may be visible to software even though the overall instruction caused a fault. If TLB
invalidation has been delayed (see Section 4.10.4.4), such page faults may occur
even if all accesses are to the same page.

...so you are asking for trouble if you trust this construct.

What you are meant to do is put your FPU instructions in a lock (where lock is gained through guaranteed atomic instructions) so you can use them without worries.

Guaranteed atomic operations are described in 8.1.1

I cannot find in the documentation a proof to the comment that CMPXCHG8 uses an implicit lock:

wrote:

This instruction can be used with a LOCK prefix to allow the instruction to be
executed atomically. To simplify the interface to the processor’s bus, the destination
operand receives a write cycle without regard to the result of the comparison. The
destination operand is written back if the comparison fails; otherwise, the source
operand is written into the destination. (The processor never produces a locked read
without also producing a locked write.)

01 May 2011, 16:21

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 01 May 2011, 16:39

1)
fild (end fist) does not accesses data larger than a qword

2)
"Guaranteed atomic operations are described in 8.1.1"
thank you, but I know and I use that long ago.
cmpxchg8b, lock ...
Here, with the fpu, it's just for the fun. Wink

"cmpxchg8b" does not use a implicit lock
only true with "xchg"
i use this ... 300% ok.

Code:

              push    ss
                pop     ss
      lock  cmpxchg8b [esi]

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

01 May 2011, 16:39

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 01 May 2011, 16:52

If fild/fist combo does not access data larger than a qword then your data might be rounded according to floating point rules.
When you want your lock to work, you need to have 80-bit fild/fist and that is definitely NOT guaranteed to be atomic (1 QWORD+1 WORD).

01 May 2011, 16:52

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 01 May 2011, 17:38

Quote:

1 QWORD+1 WORD

80 bits ... it's inside de fpu ... not outside.

fild and fist, read an write max a 1 qword ...not 1 qword + 1 word

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

01 May 2011, 17:38

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 01 May 2011, 18:07

Oops, my bad! I was not thinking it through - of course fild/fist qword[mem] will work.

01 May 2011, 18:07

revolution
When all else fails, read the source

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

revolution 02 May 2011, 01:13

Madis731 wrote:

Oops, my bad! I was not thinking it through - of course fild/fist qword[mem] will work.

Not guaranteed.

Only FILD is guaranteed not to round. FISTP does not offer that guarantee. AFAIK all current implementations of FISTP do work but the docs provide no guarantee of that. Use at your own risk.

Why not just use MMX? That is the sort of thing it is meant for.

02 May 2011, 01:13

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 02 May 2011, 07:12

with FIST, it's mathematical !
with 64 bits of mantissa, it is simply impossible that an integer be rounded!
or so, 1+1 is no longer equal to 10

Quote:

FILD (intel 2A)
It is loaded without rounding errors.
FIST (intel 2A)
If the source value is a non-integral value,
it is rounded to an integer value

from a FILD without rounding,
FIST will always store an integral value.

Quote:

Why not just use MMX? That is the sort of thing it is meant for.

an MMX register is simply the mantissa of a float Wink

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

02 May 2011, 07:12

revolution
When all else fails, read the source

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

revolution 02 May 2011, 08:52

ouadji: Don't for get about the precision setting within the FPU. Sometimes even integers get rounded to other integers. Also the rounding setting has four modes.

02 May 2011, 08:52

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 02 May 2011, 09:42

it's just a left shift of the mantissa by the exponent.
the rounding is not possible with an integer and a 64 bits mantissa.
Whatever the rounding ... since there will be no rounding.

revolution,
give me an example of rounding with an integer/fild/fist ...
and I'm moving to offer you a drink! Razz

A integer

FILD A
FIADD 0
FIST A

my god, the result would not be always equal to A

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

02 May 2011, 09:42

revolution
When all else fails, read the source

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

revolution 02 May 2011, 10:34

ouadji: I'm not arguing about the technical ability of an 80 bit FPU register to store a 64 bit value without error. I already stated above that all current implementations that I know of can, and do, recover the integer without error. But you must understand that the documents do not guarantee this behaviour.

If someone were to change the precision mode to 24 bits can you guarantee that all future incarnations of the FPU in all CPUs will not truncate the internal value to 24 bits before conversion to integer?

02 May 2011, 10:34

bitshifter

Joined: 04 Dec 2007
Posts: 790
Location: Massachusetts, USA

bitshifter 02 May 2011, 10:47

Code:

fild [int]
fiadd [zero]
fistp [int]

Not sure what youre getting at but input == output here...

Although float -> integer rounds down below 0.5, and up if above...

Ex:

Code:

fld [f14]    ;1.4
fistp [int]  ;rounds down to 1

fld [f15]    ;1.5
fistp [int]  ;rounds up to 2

Or are we talking the other way around (int -> float) ???

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.

02 May 2011, 10:47

revolution
When all else fails, read the source

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

revolution 02 May 2011, 11:15

ouadji wrote:

FILD A
FIADD 0
FIST A

This is a good example of what can go wrong when using the FPU. The F(I)ADD instruction is only guaranteed to generate enough bits of precision as specified in the FPU control word. While adding zero would appear to be a NOP, it is not. The 24 bit result of adding zero might not be enough precision to recover the original value before adding zero.

Now, let's be sure to add that if you were to try this on your x86 FPU then currently you would not find any problem. But once again, this is not guaranteed. The result is only guaranteed to have enough bits as required by the precision setting. The fact that you currently get more bits of precision is just a bonus and should not be relied upon to always be true.

02 May 2011, 11:15

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 02 May 2011, 18:51

Quote:

The 24 bit result of adding...

Code:

FILD  qword[A]  ;80bits float(16+64) <--- 64 bits integer

FIADD dword[B]  ;32 bits

FISTP qword[A]  ;80bits float(16+64) ---> 64 bits integer

where do you see 24-bit here ?

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

02 May 2011, 18:51

revolution
When all else fails, read the source

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

revolution 02 May 2011, 23:55

ouadji wrote:

where do you see 24-bit here ?

The precision control field in the control word.

Let me ask you this: Would you agree that the following should not change the value of [value]?

Code:

fild qword[value]
fld1
fdivp ;st0 = value / 1
fistp qword[value]

02 May 2011, 23:55

ouadji

Joined: 24 Dec 2008
Posts: 1081
Location: Belgium

ouadji 03 May 2011, 00:37

you won! checkmate! Wink

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

03 May 2011, 00:37

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