Currently:
Not yet implemented: td(i)
Implemented, not tested: ldarx, stdcx.
All common-mode int & fp insns in 64bit-mode tested.
Altivec insns in 64bit-mode still to be tested.
git-svn-id: svn://svn.valgrind.org/vex/trunk@1503
Backend:
- separated shifts from other alu ops
- gave {shift, mul, div, cmp} ops a bool to indicate 32|64bit insn
- fixed and implemented more mode64 cases
Also improved some IR by moving imm's to right arg of binop - backend assumes this.
All integer ppc32 insns now pass switchback tests in 64bit mode.
(ppc64-only insns not yet fully tested)
git-svn-id: svn://svn.valgrind.org/vex/trunk@1498
dispatchers CALLing generated code which later RETs, dispatchers
jump to generated code and it jumps back to the dispatcher. This
removes two memory references per translation run and by itself
gives a measureable performance improvement on P4. As a result,
there is new plumbing so that the caller of LibVEX_Translate can
supply the address of the dispatcher to jump back to.
This probably breaks all other targets. Do not update.
- Administrative cleanup: LibVEX_Translate has an excessive
number of arguments. Remove them all and instead add a struct
by which the arguments are supplied. Add further comments
about the meaning of some fields.
git-svn-id: svn://svn.valgrind.org/vex/trunk@1494
- no longer using home-grown linker - simply compiling and linking switchback.c with test_xxx.c
- updated to handle ppc64 (along with it's weirdo function descriptors...)
- have to be careful not to use exported functions from libvex_arch_linux.a, hence vex_printf -> vexxx_printf in test_xxx.c
git-svn-id: svn://svn.valgrind.org/vex/trunk@1490
- all immediates now use ULongs
- some change in register usage conventions
Implemented most insns for mode64, plus most ppc64-only instructions
- new Iop_DivU/S64
Fixed couple of bugs in backend:
- iselIntExpr_RI must sign-extend immediates
- hdefs.c::Iop_Mul16/32: set syned = False
Currently runs several test programs succesfully via the switchbacker (bzip, emfloat), but still dies with real progs.
git-svn-id: svn://svn.valgrind.org/vex/trunk@1488
- lfsu, stfsu, stfsux
Note: fp store single precision insns are being rounded twice, giving a loss of precision... this needs some thinking to solve properly...
git-svn-id: svn://svn.valgrind.org/vex/trunk@1482
than one that is potentially proportional to the length of the input
BB. This changes its complexity from quadratic to linear (in the
length of the BB) and gives a noticable increase in the overall speed
of vex. The tradeoff is that it can no longer guarantee to build
maximal trees, but in practice in only rarely fails to do so (about 1
in 100 bbs) and so the resulting degradation in code quality is
completely insignificant (unmeasurable).
git-svn-id: svn://svn.valgrind.org/vex/trunk@1474
Rough 'n ready IR used - results will be rounded along the way, not just at the end of the calculations, giving some error.
git-svn-id: svn://svn.valgrind.org/vex/trunk@1457
--------
Added a bunch of altivec float insns:
vaddfp, vsubfp, vmaxfp, vminfp,
vrefp, vrsqrtefp
vcmpgefp, vcmpgtfp, vcmpbfp
Made use of fact that ppc backend for compare insns return
zero'd lanes if either of the corresponding args is a nan.
- perhaps better to have an irop Iop_isNan32Fx4, but seems unecessary work until we get into running non-native code through vex.
- better still, tighten down the spec for compare irops wrt nan
Backend
-------
Separated av float ops to own insn group - they're only ever type 32x4
Added av float unary insns
Added av float cmp insns - for irops that don't map directly to native insns, native behaviour wrt nan's is followed, requiring lane value==nan comparisons for each argument vector.
git-svn-id: svn://svn.valgrind.org/vex/trunk@1456
