I just ran into a problem. I do not remember that this was true before, at least with 512 sector files, but I just found out that an API CreateFile for read destroys at least xmm0, xmm1 and xmm2 when dealing with 4096 BYTE sector drives. Is this something new with Win 7?
Does anyone know what other APIs may destroy the xmm regs?
Dave
for x32 all XMM registers are volatile, thus any API can "destroy" the registers. For x64 XMM6-15 are nonvolatile (see fastcall).
I don't know whether to thank you or not, but thank you for the info.
Yes, I'm using x32 code on my Win7 64 bit system. I have never tried 64 bit assembly.
I generally open a file, set up registers, then process the data. In my current case, I was trying to process many files one after the other and wanted to hold data in the xmms.
I guess, I will have to just use data storage. Would have been nice to be able to use regs.
Dave.
Quote from: KeepingRealBusy on November 26, 2013, 09:29:43 AM
I don't know whether to thank you or not, but thank you for the info.
qWord is only the messenger ;)
Here is an old thread discussing this problem. (http://masm32.com/board/index.php?topic=292.0) It's indeed only x32 code on Win7-64 that trashes xmm regs.
Oh, I'm not unhappy with QWord. I'm not unhappy with the messenger, just unhappy with the message. The fact that this is only with x32 code on an x64 platform explains why I have not see much of this as a problem before (since 2000 or so I have been on an XP system, just recently moved to this Win 7 laptop).
This is not a disaster, I just have to save and reload the registers around the file open call. I will, however, not embed this save/restore in my wrapper for the I/O since I do not
normally need to preserve the xmm regs around any API call.
Dave.
Hi,
Would running the programs in some sort of virtual PC have
any effect on preserving the registers?
Regards,
Steve N.
i think it's a matter of knowing, in advance, that the registers are destroyed
he's now in a mode where he is trying to make his existing code work correctly
but, had he known, he would have designed the program differently
Steve,
I haven't played around with virtual boxes. My impression is that executing in a virtual box would cause execution times to get longer. I am trying to get things to run faster, not slower.
My fixes for the problem worked.
dedndave,
You posted your reply as I was typing mine. Yes the fixes worked just fine.
Dave.
Hi Dave
Quote from: KeepingRealBusy on November 27, 2013, 03:10:01 AM
I haven't played around with virtual boxes. My impression is that executing in a virtual box would cause execution times to get longer. I am trying to get things to run faster, not slower.
I think you are right in assuming it would be slower. I guess
I was just curious as too how effective a virtual PC might be.
Quote
My fixes for the problem worked.
Good.
Regards,
Steve N.
Quote from: KeepingRealBusy on November 27, 2013, 03:10:01 AMexecuting in a virtual box would cause execution times to get longer.
The speed loss is hardly measurable. Virtual PCs and (slow) emulators are completely different animals.
The XMM instructions are processed by the same registers as those used for processing floating point instructions (the FPU). Ever since those XMM instructions have been available, the MS staff have used them to perform most (if not all, even for 2+2) number crunching. Any API requiring whatever number crunching, such as sizing a window, would thus destroy any data in those registers. This has been reported many, many years ago in this forum.
you're thinking of MMX registers, Ray
:redface:
Must have been reading it backwards.
Quote from: raymond on November 27, 2013, 02:42:34 PM
:redface:
Must have been reading it backwards.
This can sometimes happen. Never mind.
Gunther
Greetings to all,
I was not aware of this particularity either. In my (32 bits) project, I keep 2 variables in xmm0 & xmm2, and in some cases, I call ReadFile & Writefile APIs.
Could someone using Windows 64 bits confirm me if those 2 functions thrash xmm registers as well, please ?
Or better, run my compression program on enwik9 benchmarking file ( http://mattmahoney.net/dc/enwik9.zip (http://mattmahoney.net/dc/enwik9.zip)) , and tell me if the compressed filesize is still 183 459 153 bytes?
Syntax would be: SMAC /c enwik9
Look out: compression uses arithmetic coding+context mixing, so it is very slow (70 minutes on my Core 2 duo Merom).
Thanks for your help!
Hi Jean-Marie,
Whether the test fails or not (you must find a volunteer who is willing to overheat his CPU for an hour - good luck 8)): You can't release a prog that relies on an undocumented feature, i.e. "my tests showed that ReadFile doesn't trash xmm0". In the next Windows update, it might trash xmm0...
Apart from this warning: Welcome to the forum :icon14:
P.S.: We have a reputation of being able to speed up slow programs. Show us your innermost loop...
Thanks jj2007,
Yes, now I have figured out that I'll have to make some changes. I was just curious to know if I was lucky or not this time (habitually I'm not).
There are a lot of "hotspots" in my program, the main one beeing the Stretch function. But may be I'll have to discuss this on a new thread (don't want to pollute this one).
Hi Jean-Marie,
welcome to the forum. Show us your code and we'll see what we can do.
Gunther