Small success story is here: I found an AthlonXP+WinXP box and tried debug build with /arch:SSE. Jitrino loaded successfully, but vmi.dll and both GCs appeared to depend on MSVCR71D.DLL which is not in the harmony bundle and does not exist in system w/o MSVC installed. After replacing those dlls with release versions, I was able to work on Eclipse and observed no errors. Though it was painfully slow I must admit :(. I hope HARMONY-3737 will improve client experience, + we may consider downgrading jitted code for non-SSE2-capable CPUs to SSE at least, not to x87 level.
Next I tried to run Forte3.0CE installer and met assertion in Ia32i586InstsExpansion.cpp - success story ended ;). I'll create JIRAs for the met problems. -- Alexey 2007/5/25, Nathan Beyer <[EMAIL PROTECTED]>:
BTW - I do have P3 machines for testing. One's running W2K and the other's running Ubuntu. -Nathan On 5/24/07, Elford, Chris L <[EMAIL PROTECTED]> wrote: > FYI, I have created http://issues.apache.org/jira/browse/HARMONY-3961 > To reflect this desired behavior. > > Regards, > Chris Elford > Intel SSG/Enterprise Solutions Software Division > > -----Original Message----- > From: Elford, Chris L [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 24, 2007 9:46 AM > To: [email protected] > Subject: RE: problem under windows > > Interesting. Its good to hear that some thought has been given to P3 > class systems. I would think /arch:SSE would be okay. This would let > us run on both P3s and Athlon (like the one that Michael was trying to > run on) which support both MMX and SSE but not SSE2. > > Is there a compiler option that generates back-off MMX code on platforms > that don't support SSE or SSE2 instructions? If so, it would result in > larger executables and might impact code locality but it might be a good > tradeoff. > > Regards, > > Chris Elford > Intel SSG/Enterprise Solutions Software Division > > -----Original Message----- > From: Mikhail Fursov [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 24, 2007 2:12 AM > To: [email protected] > Subject: Re: problem under windows > > Well, it looks like we need to remove this line from jitrino.dll build > configuration for 32bit platform. > <compilerarg value="/arch:SSE2" /> > > On 5/24/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > > > On 5/24/07, Elford, Chris L <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > > > > I tracked down a system that has SSE but not SSE2 (a dual > processor P3 > > > system). For me, adding "-xe ii" to the ntsd command line let the > > > debugger break in at the first chance exception. It reports that > what I > > > > > > believe is an SSE2 instruction does indeed happen during jitrino.dll > > > startup. > > > > > > 01365fb0 f20f100520553901 movsd xmm0,qword ptr > > > [jitrino!JIT_gc_start+0xd5810 (01395520)] > > > > > > Without jitrino symbol information ( e.g., a pdb file for > jitrino.dll), > > > its hard to tell what function is being executed (it is unlikely > that it > > > is JIT_gc_start. It would be nice if the snapshot builds included > > > symbol files to help make for more meaningful stack traces. > > > > > > It may be good to discuss [again?] on the lists whether more people > can > > > come into the project to help create legacy modes that earlier > > > instruction sets (and earlier Oses) can still execute without > crippling > > > current instruction set processors (and/or OSes). > > > > > > I don't see an open JIRA about this one. The closest I see is > > > http://issues.apache.org/jira/browse/HARMONY-3246 which is more > about > > > code that the JIT creates rather than the JIT itself. > > > > > > Ntsd log below showing more detail around faulting instruction. > > > Mikhail? > > > > > > You're right that we fixed Jitrino.OPT to generate SSE independent > code > > (use x87) if SSE2 is not available. > > Another JIRA (not commited yet): > http://issues.apache.org/jira/browse/HARMONY-3737 > > makes JET to compile all methods without FPU insts (>90% of methods) > and > > pass other methods to OPT > > I checked dumpbin /disasm for jitrino.dll and see a lot of SSE/SSE2 > insts > > in code. > > > > It's possible that our compiler options for jitrino.dll are too > > aggressive. I will check it and report. > > > > -- > > Mikhail Fursov > > > > > -- > Mikhail Fursov >
