Daryl -- I would note that for 64-bit x86 (2.3.4.2) it explicitly describes the usage of XMM registers. These are non-int usages but the preservation rules are listed.
The registers Rax, Rcx Rdx R8, R9, R10, R11, and XMM0-XMM5 are volatile and are, therefore, destroyed on function calls. The registers RBX, RBP, RDI, RSI, R12, R13, R14, R15, and XMM6-XMM15 are considered nonvolatile and must be saved and restored by a function that uses them. Function pointers are pointers to the label of the respective function and don't require special treatment. And For MMX, XMM and floating-point values, return values that can fit into 64-bits are returned through RAX (including MMX types). However, XMM 128-bit types, floats, and doubles are returned in XMM0. The floating point status register is not saved by the target function. Floating-point and double-precision arguments are passed in XMM0 - XMM3 (up to 4) with the integer slot (RCX, RDX, R8, and R9) that would normally be used for that cardinal slot being ignored (see example) and vice versa. XMM types are never passed by immediate value but rather a pointer will be passed to memory allocated by the caller. MMX types will be passed as if they were integers of the same size. Callees must not unmask exceptions without providing correct exception handlers. For 32-bit (2.3.2.2) x86 In addition, unless otherwise specified by the function definition, all other registers (including MMX and XMM) are preserved. The floating point status register is not preserved by the target function. The floating point control register and MMX control register are saved by the target function. If the return value is a float or a double, the value is returned in ST(0). -----Original Message----- From: Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com] Sent: Friday, September 05, 2014 11:41 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] VS2013 build failures: unresolved external symbol __dtoui3 Scott, Thank you for reporting this. I have added it to the list of issues to be resolved for StdLib. Regrettably, I haven't done any testing with VS2013. While one is free to use the SSEx and MMX registers and instructions in their own code, it isn't a supported feature of EDK II. A compilation unit using these extensions must confine all artifacts of such use within the compilation unit. No assumptions may be made about external code's use, preservation, or destruction of these registers. Within a compilation unit, one is free to use any calling convention supported by the target compilers, as long as all public APIs use the EFIAPI calling convention, which does not address these registers. Regarding your questions: 1) I don't know about combining modules compiled with /arch:SSE2 and /arch:SSE. My assumption has been that both of these have been "turned off" since we didn't want the compiler generating these instructions. It looks like I need to do some more research in this area. 2) The ftol2.obj binary is compatible with VS2003 through VS2012. I don't yet know about VS2013. Daryl McDaniel "It is the mark of an educated mind to be able to entertain a thought without accepting it." - Aristotle -----Original Message----- From: Scott Duplichan [mailto:sc...@notabs.org] Sent: Thursday, September 04, 2014 9:41 PM To: edk2-devel@lists.sourceforge.net Subject: [edk2] VS2013 build failures: unresolved external symbol __dtoui3 Building AppPkg for IA32 using VS2013 fails with unresolved external symbol __dtoui3. __dtoui3 is a helper function called by the generated code. It is analogous to the __ftol2 helper function call generated by older Microsoft compilers. VS2013 calls __dtoui3 instead of __ftol2. Apparently the new function converts double to integer with reduced use of the x87 fpu. The call to __ftol2 generated by older Microsoft compilers is resolved by binary file StdLib\LibC\Main\Ia32\ftol2.obj, an object extracted from Microsoft libs. The same approach could be used for VS2013's __dtoui3 by extracting ftol3.obj and adding it to EDK2. But doing so causes unresolved external symbol __except1. This can be fixed by extracting fpexcept.obj from VS2013 libs and adding it to EDK2. But once that is done, 12 more unresolved externals are created. Another approach is to use /arch:SSE when building LibGdtoa for IA32 with VS2013 (default is /arch:SSE2). This causes VS2013 to generate a call to __ftol2 instead of __dtoui3 and resolves the build failure. I suppose this is the route to take. Concerns are: 1) Is it OK to combine modules compiled with /arch:SSE2 and /arch:SSE? 2) Is the current EDK2 ftol2.obj binary compatible with all supported Microsoft compilers, including VS2013? I will do some testing and submit a patch if it looks OK. Thanks, Scott ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
