Currently we require th Tamarin embedder to detect SSE2 presence and tell us whether we can use it or not. Since all Tamarin embedders on Windows and Linux-x86 will need this functionality, it should be moved into Tamarin, since the best the embedder can do is get it right, and the worst is to get it wrong (leading to subpar performance or crashes).
10 years ago
SSE2 detection is an instance of SWAR detection (where SWAR = SIMD Within a Register). I am spending some time looking at possible systematic approaches to dynamic SWAR detection involving that could potentially apply to Tamarin as well as other applications and SSE2 as well as other architectures. I am concerned about different projects each doing part of the job and having a mixed bag of corner cases that don't quite work. Note that there is substantial evolution of SWAR support in processors at the present time, so this problem is becoming increasingly important. Here are some of my initial notes. 1. Support for SWAR detection should likely be considered separately from general SWAR support. The basic reason is that SWAR detection is a function that needs to run on a family of processors that share a common set of generic instructions, but which may differ in whether SWAR operations are supported or not and what the level of that support is. For example, the ia32 family may include SWAR support for MMX, SSE, SSE2, SSE3, SSE4 and so on. The ppc family may include SWAR support for Altivec (=VMX) or not. The SWAR detector must be able to run successfully on processors within these families even when the SWAR support is lacking. Therefore, it must be encapsulated in a unit that is compiled without any of the relevant SWAR flags (e.g., -msse2 or -maltivec). 2. The CPUID instruction can be used on ia32 to query whether a particular processor supports various features. However, each vendor of compatible processors can provide their own specification and implementation of CPUID. This adds complexity and creates the challenge of updating detection logic as processors evolve and further options become available. Intel and AMD documentation for CPUID are available here. http://download.intel.com/design/processor/applnots/24161832.pdf http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf 3. Processor detection may also be supported by the underlying operating system. For example, the following link includes recommendations for Altivec processor detection under Mac OS X. http://developer.apple.com/hardwaredrivers/ve/g3_compatibility.html 4. Another OS issue is whether the SWAR operations are allowed by the OS or not. There are cases where it is not, even if the processor is capable. 5. Illegal instruction trapping. Various cases of CPU detection that you can find out there are based on the method of illegal instruction trapping. In essence, try a desired SWAR operation sequence and see if it excecutes successfully. If not, capture the SIGILL interrupt and report that the requested SWAR processing is not available. Is this a general solution to the problem or should it only be used when no other methods are known to work? Can we capture this in a general bit of logic? Even if it cannot be used for all cases, it does seem worth trying to define it in a generic way, so that one common code base could be used for the cases where it is relevant.
Looks like bug# 500466 depends on this issue and it is currently targeted for the current release.
If nanojit ever evolves to support more interesting SIMD across different architectures then Rob's comment should be revisited, but for now, we're only interested in x86. Since bug 500466 has been resolved , I'm closing this.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Verified, build system is testing JIT on non-sse2 hardware (windows-p3-deep)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.