first priority is 32bit mac osx
Created attachment 341542 [details] [diff] [review] Machine dependent content has been removed from Assembler.cpp Machine dependent content has been moved out of Assembler.cpp to Nativei386.cpp and NativeThumb.cpp to simplify future ports to Power PC and additional platform
Since there are a lot of patches being developed in parallel for nanojit, it would be better to not do any unnecessary reformatting until we reach a stable point. Assembler.cpp in particular has lots of diff blocks that are just spacing and indentation. lets revert those changes. Once the major patches are all done and landed we can do a single reformat patch. I think printActivationState() should remain cpu-independent, its not clear why ARM needs to be ifdef'd in there at all? is it just a bug being worked around? Lastly, and i hate to inflict this, but we should rebase this work so it's based on a recent tamarin-redux stable point, instead of tamarin-central. (tamarin-redux contains all of what is in tamarin-central so it should just be a forward merge). the latest tamarin-redux added a separate NativeARM.cpp to keep ARM stuff separate from Thumb.
Created attachment 342129 [details] [diff] [review] ver1 reapply vlad's changes to latest redux and minimize the diffs. Tested and running on mac only.
Comment on attachment 342129 [details] [diff] [review] ver1 watch out for unintended xcode project file changes, that compatibilityVersion attribute keeps coming and going...
compiles for winmobile and x64, but haven't run tests against it.
pushed...and whoops forgot to exclude the xcode project file. And yes its annoying.
Looks like you broke the ARM build.
Sorry to cause pain didn't recognize that autobuilds for ARM weren't including NJ.
partly working prototype can be found in http://hg.mozilla.org/users/edwsmith_adobe.com/ppcjit todo: * ppc64 * saved fpu registers (F14-F31) * use multi-load/store for saved regs * patching far branches >24bit * use float multiply-add instructions (even without intermediate rounding?) * avoid condition register contention with cror * save/restore CR2-4? (currently not used) * use dedicated stack area for saved regs? * use R2 (TOC) as scratch on mac? which platforms dedicate TOC? * debug the test suite & esc * LIR_x,xt,xf,loop, frag patching * fold addressing modes * i2d & u2d helper functions? is alignment okay with "lfd f, 12(sp)"?
just hit 0 failures in test/acceptance performance on dual cpu 2.7Ghz G5 powermac: avm: ../../../redux/objdir-r/shell/avmshell -Ojit (MIR) avm2: ../../../ppcjit/objdir-r/shell/avmshell -Ojit (nanojit) iterations: 1 test MIR LIR %sp metric misc/boids.as 7552 6578 14.8 time misc/boidshack.as 1911 1765 8.3 time misc/gameoflife.as 11718 10747 9.0 time misc/primes.as 52341 48318 8.3 time scimark/FFT.as 9122 7514 21.4 time scimark/LU.as 10003 7278 37.4 time scimark/MonteCarlo.as 11143 6669 67.1 time scimark/SOR.as 6621 6018 10.0 time scimark/SparseCompRow.as 4378 4396 -0.4 time
Created attachment 350886 [details] [diff] [review] cleanup patch to prepare for adding ppc support This just cleans up some code to better support big endian and 64bit RegisterMask, but does not add PPC support. The big-endian fixes might be useful for the Sparc port too.
Created attachment 350889 [details] [diff] [review] nanojit backend for 32bit PowerPC needs more range limit testing, and ignore the jitcount/jitmax debug cruft. (see above todo list).
Comment on attachment 350889 [details] [diff] [review] nanojit backend for 32bit PowerPC Looks good so far. There are a few TODO() calls still in there which I suspect need work. Also I'm wondering if we can use the API porting layer all the time; i.e. get rid of icache_flush
yeah, the icache_flush code needs to be cleaned up, and also the code to mark memory as executable also needs cleanup. we can model a NJ porting layer the same way as we're doing with VMPI. (NJPI?)
(In reply to comment #14) > yeah, the icache_flush code needs to be cleaned up, and also the code to mark > memory as executable also needs cleanup. we can model a NJ porting layer the > same way as we're doing with VMPI. (NJPI?) Configurability & portability are already very low, please stick to a single platform layer :-)
Comment on attachment 350886 [details] [diff] [review] cleanup patch to prepare for adding ppc support pushed to tamarin-redux as 1180:988439d954d9
Created attachment 351430 [details] [diff] [review] hopefully final patch, only TODOs are trace specific, PEDANTIC is happy. This should be final (sandbox build running now). since the last patch: * added & debugged PEDANTIC mode * fixed remaining TODOs that apply to tamarin * added cmpwi and cmplwi optimization * cleaned up nPatchBranch performance vs MIR avm: ../../../redux/objdir-r/shell/avmshell -Ojit avm2: ../../../ppcjit/objdir-r/shell/avmshell -Ojit iterations: 1 test avm avm2 %sp metric misc/boids.as 7764 7378 5.2 misc/boidshack.as 2062 1884 9.4 misc/gameoflife.as 12594 10706 17.6 misc/primes.as 54065 46614 16.0 scimark/FFT.as 9146 8228 11.2 scimark/LU.as 10059 7997 25.8 scimark/MonteCarlo.as 11192 6887 62.5 scimark/SOR.as 6550 6610 -0.9 scimark/SparseCompRow.as 4447 4507 -1.3
Comment on attachment 351430 [details] [diff] [review] hopefully final patch, only TODOs are trace specific, PEDANTIC is happy. Marking + for review of all non-ppc changes, since I don't want to hold up the submit. Will eye-ball the ppc files later.
pushed to tamarin-redux as 1198:63bf07dcdb6d Will leave this bug open pending final review
changes are now in tamarin-redux. deleted working repository at http://hg.mozilla.org/users/edwsmith_adobe.com/ppcjit
any chance to porting to mozilla-central?
> any chance to porting to mozilla-central? If you indirectly mean SpiderMonkey then yes, I imagine the code will eventually land in that repo. BTW, if you like ppc have a look at bug #468445