Intel® ISA Extensions
Use hardware-based isolation and memory encryption to provide more code protection in your solutions.

RTM/HLE abort while write to X87 control-word?

Oliver_K_
Beginner
470 Views

Hi,

Intel's documentation 'Intel 64 and IA-32 Architectues Software Developer's Manual Vol-1' mentions in section section 16.3.8.1 that a transaction will be aborted if X87 state is modified (including all X87 instructions).

But what about fldcw? The calling convention of the 'SYSV ABI for X86_64' requires to preserve/restore the X87 control word.

Does 'all X87 instructions' include fldcw?

Oliver

0 Kudos
4 Replies
James_C_Intel2
Employee
470 Views

Does 'all X87 instructions' include fldcw?

Yes. I believe so. I can't get to the site that holds the SYSV documentation you reference, but Agner Fog's summary says 

 

Floating point control word and MXCSR register
The floating point control word and bit 6-15 of the MXCSR register must be saved and
restored before any call or return by any procedure that needs to modify them, except for
procedures that have the purpose of changing these.

So unless you are modifying them you don't need to touch them, and there seems no reason to modify them unless you're about to use other instructions which are TSX unfriendly...

0 Kudos
Oliver_K_
Beginner
470 Views

Hello James,

I'm using code that does cooperative scheduling (user-land threads) - the routine that does the context switch to another user-land thread (exchange stack and instruction pointer) is forced (according the calling convention) to touch the x86 control word.

The used library hands-over locked spinlocks from one to another user-land thread that unlocks the spinlock.

I thought it would be a good idea to use HLE in order to get more performance because most of the time the critical section/memory, protected by the spinlock, is not touched by other logical cpus.

My hope was that HLE will still work because the ST(0)-ST(7) registers are not modified.

Oliver

0 Kudos
jimdempseyatthecove
Honored Contributor III
470 Views

I agree with James. The description of your coding choice is analogous to co-routine calling method. If the routines you are calling (stack switch and program counter switch) do not mess with x87 then there is no requirement to save/restore x87 state (same goes for SSE/AVX/AVX2/AVX512).

Note, this said, the next programmer might mess with the x87. So it might behoove you to add conditional compile code for debug build to (prior to HLE) save the state, run your HLE code, then following HLE region a conditional compile section to assert that the x87 state did not change. IOW enforce your rule about what can or cannot be done in the other user-land thread.

By the way, why can you not save the x87 state prior to your protected region? 

Jim Dempsey

0 Kudos
Oliver_K_
Beginner
470 Views

I'm sorry, you comment does confuse me a little bit.

yes, its the context of co-routines, fibers, user-land threads ...

Suppose the context switch is done by function jump() (see appended file) - it accepts a pointer to the stack that has to be resumed and returns a pointer to the stack that has been suspended (the stack is used as storage for the preserved registers).

Because the implementation of jump() is called from other C functions, it has to fulfill the calling convention, e.g. SYSV requires that x87 status word is callee saved and Win64 requires to preserve registers XMM6-XMM15.

void foo( void * resume) {

   void * suspend = jump( resume); // context switch

}

The problem is how to know if the code that calls foo() has or has not modified the x87 control word (I believe that's what you are suggesting).

Additionally, the code of the resumed context might or might not modify x87. Without TSX in mind it seamed to me the safest to preserve/restore the x87 control word in each case.

Edit: now I get it - x87 cw store/restore has to be removed from jump():

- inside the spinlock I preserve x87 before XACQUIRE

- call jump() // context switch without x87

- inside spinlock call XRELEASE and then restore x87 cw

 

0 Kudos
Reply