This patch defines new makefile command line paramaters to better control the
ARM specific options. The new paramters are
* armfpu = vfp, vfpv3-d16, vfpv3, neon.
* armfloatabi = softfp, hard
* armneon = on
* armthumb = on, off
* armtest = on
One existing paratemer has been modified:
* armv7 = true, false
A number of parameters have been deprecated (but are still working):
* hardfp = on, off
* vfp2 = off
* vfp3 = off
the armtest paratmer when set to "on" will lock the options used during compile
time at runtime. This allows for example to easily test the ARMv6 build on an
ARMv7 platform without having to worry about features detected at runtime. When
not specified the compiler default will be used meaning it is not necessary
anymore to specify hardfp=on when natively building on an hardfp platform.
The shell help now prints the target options and features detected.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/14263018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14288 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
First of all, it has nothing to do with Isolates, it is related to the assembler
at hand. Furthermore, the saving/restoring is platform-independent. Cleaned up
some platform-specific stuff on the way.
Note that there are some things which still need some cleanup, like e.g. using
EnumSet instead of uint64_t, making Probe() more uniform across platforms etc.,
but the CL is already big enough.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12391055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch makes us generate faster code for DoStoreKeyedFixedDoubleArray,
by using a branch rather than a conditional Vmov instruction.
Conditional VFP instructions are not a great idea in general, and it was
especially bad in this case because Vmov expands to a bunch of instructions.
For this reason, the patch also removes the 'cond' parameter from Vmov.
Thanks to Rodolph for pointing me to this!
BUG=none
Review URL: https://chromiumcodereview.appspot.com/12316096
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13722 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The assembler has 8 different vmov variants. The one for vmov.32 and for moving
an immediate into a double reg only differs in the type of the second
paremeter: vmov.32 takes an int, the other takes a double.
The situation is dangerous because C++ will happily implicitly convert between
int and double.
This patch changes the signature of the vmov.32 assembler function so that it
cannot be confused with the other vmovs.
BUG=none
Review URL: https://chromiumcodereview.appspot.com/12255031
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The previously-used instruction isn't guaranteed to always be undefined,
and the encoding used was conditional (failing the condition on an
undefined instruction is itself undefined and not guaranteed to
fault!). I would have like to use a more clever encoding (see bug 2963),
but we need the extra bits to encode the size of the constant pool.
BUG=security
R=ulan@chromium.org
Review URL: https://chromiumcodereview.appspot.com/11242002
Patch from JF Bastien <jfb@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12791 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
regardless of the detected CPU. This is a requirement for the
debugger and the deoptimizer, which both expect that code from
the snapshot (compiled without VFP and ARM7) should have the
same layout as code compiled later.
This is another change to make snapshots more robust with
arbitrary code.
Review URL: https://chromiumcodereview.appspot.com/10824235
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12287 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances are never deleted).
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This static initializer populates a structure used by x86 atomic operations. It seems that we can hardly remove it. If possible, it will be removed in a next CL.
This CL also modifies the presubmit script to check the number of static initializers.
BUG=v8:1859
Review URL: https://chromiumcodereview.appspot.com/9666052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The ARM and MIPS assemblers had a bug where they did not handle the last element
in the list of code positions correctly during the fixup of offsets for forward
jumps. This happened when the first instruction contained a forward jump to a
label, and that label was used in a forward jump later, too.
Unified the code for Assembler::next on ARM and MIPS while we were there.
Added test cases, even for ia32/x64, which seem to be correct, even I don't
fully understand why... %-}
BUG=v8:1644
Review URL: http://codereview.chromium.org/7786001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
C++'s 'great' idea of implicitly converting an enum to an integral value hit us
again, this time resulting in silly (but currently non-harmful) entries in the
relocation table. Encapsulated the AST ID recording a bit, which helped a lot to
find the culprit.
Review URL: http://codereview.chromium.org/7400016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8671 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
