flat assembler
Message board for the users of flat assembler.

Index > Main > fist(p)

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



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

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)- Image
Post 30 Apr 2011, 21:07
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: 17247
Location: In your JS exploiting you and your system
revolution
No.

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

It is in the docs.
Post 01 May 2011, 01:33
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:

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)- Image
Post 01 May 2011, 07:21
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: 17247
Location: In your JS exploiting you and your system
revolution
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!
Post 01 May 2011, 09:35
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:

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)- Image
Post 01 May 2011, 15:49
View user's profile Send private message Send e-mail Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
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.)
Post 01 May 2011, 16:21
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
ouadji



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

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)- Image
Post 01 May 2011, 16:39
View user's profile Send private message Send e-mail Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
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).
Post 01 May 2011, 16:52
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
ouadji



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

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)- Image
Post 01 May 2011, 17:38
View user's profile Send private message Send e-mail Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
Oops, my bad! I was not thinking it through - of course fild/fist qword[mem] will work.
Post 01 May 2011, 18:07
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17247
Location: In your JS exploiting you and your system
revolution
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.
Post 02 May 2011, 01:13
View user's profile Send private message Visit poster's website Reply with quote
ouadji



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

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)- Image
Post 02 May 2011, 07:12
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: 17247
Location: In your JS exploiting you and your system
revolution
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.
Post 02 May 2011, 08:52
View user's profile Send private message Visit poster's website Reply with quote
ouadji



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

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)- Image
Post 02 May 2011, 09:42
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: 17247
Location: In your JS exploiting you and your system
revolution
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?
Post 02 May 2011, 10:34
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
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.
Post 02 May 2011, 10:47
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17247
Location: In your JS exploiting you and your system
revolution
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.
Post 02 May 2011, 11:15
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:
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)- Image
Post 02 May 2011, 18:51
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: 17247
Location: In your JS exploiting you and your system
revolution
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]    
Post 02 May 2011, 23:55
View user's profile Send private message Visit poster's website Reply with quote
ouadji



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

you won! checkmate! Wink

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 03 May 2011, 00:37
View user's profile Send private message Send e-mail 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.

Powered by rwasa.