News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

view of fpu registers step by step

Started by ToutEnMasm, June 30, 2009, 06:46:19 AM

Previous topic - Next topic

ToutEnMasm

Hello,
This one is to make it easier to work with the fpu.
Put your fpu code in the f_callback proc,put step in it (call step) .
choose a format to view the result (float,hexa,expo,decimal).
now you can see the data registers,the state register and the control register.
Needed: at least the vc++ express edition,the libcmt is used

I want to made the same thing with sse,mmx intructions but it seems that savings the registers isn't so easy.Perhap's an idea ?.
reports are welcome.

If you have trouble with the strsafe functions see remark and zip below




[attachment deleted by admin]

ToutEnMasm


I have had a bad surprise with the new strsafe.lib.There isn't the function in use in the fpuvisu.lib.
Those functions are now in source in the header of the sdk and are unusable like that with masm.
SO,i have extracted the strsafe.obj of an old library and added this object in the new fpuvisu.lib.
With this new library you haven't need of the strsafe.lib.





clive

Quote from: ToutEnMasm
I want to made the same thing with sse,mmx intructions but it seems that savings the registers isn't so easy.Perhap's an idea ?.

Use FXSAVE and pull the STx, MMx and xMM registers from the memory image.
It could be a random act of randomness. Those happen a lot as well.

jj2007

Quote from: clive on October 10, 2010, 03:14:46 PM
Quote from: ToutEnMasm
I want to made the same thing with sse,mmx intructions but it seems that savings the registers isn't so easy.Perhap's an idea ?.

Use FXSAVE and pull the STx, MMx and xMM registers from the memory image.

The Streaming SIMD Extensions fields in the save image (XMM0-XMM7 and MXCSR) may not be loaded into the processor if the CR4.OSFXSR bit is not set. This CR4 bit must be set in order to enable execution of Streaming SIMD Extensions.

How would you set CR4.OSFXSR?

Antariy

Quote from: jj2007 on October 12, 2010, 09:02:37 PM
How would you set CR4.OSFXSR?

This is made by OS. You cannot set any CRx from usermode.



Alex

dedndave

it isn't easy to find information about how different versions of windows treat the control registers
some may be set by BIOS and not messed with by windows
others may be set by BIOS, then changed by windows
still others may be set by windows only, or left as is altegether
it is an area of complete documentation mystery

Antariy

Quote from: dedndave on October 12, 2010, 10:57:46 PM
it isn't easy to find information about how different versions of windows treat the control registers
some may be set by BIOS and not messed with by windows
others may be set by BIOS, then changed by windows
still others may be set by windows only, or left as is altegether
it is an area of complete documentation mystery

Well, this is not case for CR4.OSFXSR.
I doubt that most of BIOSes rely on such incompatible things as SSE.
If OS support and know about SSE - it set this flag, otherwise running of SSE instructions on *SSE-capable* CPU lead to #UD, and prog is crashed with fun :)



Alex

clive

Quote from: jj2007 on October 12, 2010, 09:02:37 PM
The Streaming SIMD Extensions fields in the save image (XMM0-XMM7 and MXCSR) may not be loaded into the processor if the CR4.OSFXSR bit is not set. This CR4 bit must be set in order to enable execution of Streaming SIMD Extensions.

How would you set CR4.OSFXSR?

And what clown writes a multitasking, SSE compatible OS that DOESN'T enable this? As I recall this instruction was first implemented in Deschutes (Pentium II), prior to the Katmai (Pentium 3) which supported SSE for the first time. Microsoft supported the enabling of this feature as far back as February 1998, in one beta releases of Windows 98.
It could be a random act of randomness. Those happen a lot as well.

clive

Quote from: Antariy
If OS support and know about SSE - it set this flag, otherwise running of SSE instructions on *SSE-capable* CPU lead to #UD, and prog is crashed with fun

Exactly, otherwise much hilarity would ensue.

The point for the flag in the CPUID, and the enablement in CR4 is an implicit acknowledgment by the OS that the CPU has this function, and that it should use it as the most efficient method of preserving the CPU context.

If one is concerned about executing it, then they should use an SEH around it. Or work with the kernel mode driver that can touch CR4.
It could be a random act of randomness. Those happen a lot as well.

dedndave

i agree, Clive
my point was...
where is all that documented ?
you know it, but you are sort of a wizard - lol
we can't all be fricken wizards

clive

Quote from: dedndave on October 13, 2010, 12:58:38 AM
i agree, Clive
my point was...
where is all that documented ? you know it, but you are sort of a wizard - lol we can't all be fricken wizards

Hard to say, when the features were first implemented Intel was rather sketchy with the details. Basically limiting it to preferred development partners, as the product came into main stream production the details were reflected in the technical manuals. I can certainly trace the use of FXSAVE/FXRSTOR back to early 1998 when Microsoft put it in the floating point driver for what became Windows 98, and then later in Windows 2000. It is not supported in NT 4.0 or Windows 95, but may have made it into subsequent service packs.

The BIOS's didn't tend to use/setup the control registers, they basically had to bring up DOS, and support the INT 15 functions. They deal with the A20 switch, and the fast-reset mode switching, and setting up the north bridge, south bridge, peripherals and memory. Once in DOS, things like HIMEM or EMM386, are where much of the control registers, and virtualization are setup, or ownership is taken from the BIOS.

The BIOS also looks at the CPUID, checking for and disabling the serial number function, checking the stepping of the processor and applying a microcode patch if available. Enabling and initializing the cache, and tweaking paging, memory size, or other options (MSRs) as needed or as directed by the CMOS/BIOS settings.

The BIOS writer would likely work directly with Intel engineers, and have documentation that is not generally available. A lot of the real fun aspects are covered by the chip errata, but the fixes and function of the MSR's are not well/openly documented (at least last time I care to look).
It could be a random act of randomness. Those happen a lot as well.

dedndave

well - the definition of the registers seems to be fairly well documented, as far as Intel and AMD are concerned
where the documentation is lacking is what BIOS and Windows do with them at boot


clive

Quote from: jj2007
How would you set CR4.OSFXSR?
..
Ok, so what you are saying is it's enabled by default. Although there are many clowns working for Microsoft, of course :green2

Rich clowns at that. They implemented it in the OS as soon as the processor supported it, but it clearly was not it Win 3.x or Win 95 because it was not invented at that time. The MMX register state was saved using the FSAVE/FRSTOR functions of the FPU.

The OS enables it as part of it's handling of the Math CoProcessor context, to preserve the FPU/MMX/SSE state as it switches from task-to-task. Microsoft has out-of-the-box support for FXSAVE/FXRSTOR since Windows 98 (circa Feb 98 at the time the Deschutes processor was released, it was in a beta release and might have been in earlier releases). As I recall they allocated 512 bytes for the context, but FXSAVE only writes out a portion/pieces of that, but will clearly depend on the processor, and if there is an XMM8..XMM15 set of registers.

When the processor boots CR4.OSFXSR is NOT enabled. So to use FXSAVE/FXRSTOR under DOS you have to explicitly enable it.
It could be a random act of randomness. Those happen a lot as well.

ToutEnMasm


I have just a question Now.
When mmx instruction are used , the emms instruction must be used to clear the registers before a FPU instruction.
Is there a way to test if the cpu is in fpu or mmx mode ?