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
This patchset begins by adding support for "yield", which is unlike other tokens
in JS. In a generator, whether strict or classic, it is a syntactic keyword.
In classic mode it is an identifier. In strict mode it is reserved.
This patch adds YIELD as a token to the scanner, and adapts the preparser and
parser appropriately. It also parses "function*", indicating that a function is
actually a generator, for both eagerly and lazily parsed functions.
Currently "yield" just compiles as "return".
BUG=v8:2355
TEST=mjsunit/harmony/generators-parsing
Review URL: https://codereview.chromium.org/12646003
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14116 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Addition of a compiled hydrogen stub for KeyedStores.
- Inlining of "grow" stubs into OPTIMIZED_FUNCTIONs
- Addition of new "ignore OOB" ic stub that silently swallows out-of-bounds stores to external typed arrays.
- Addition of new "copy-on-write" ic stub that inlines allocation and copying operations for cow array
- New stub are generated with Crankshaft, so they are automatically inlined into OPTIMIZED_FUNCTIONs
Review URL: https://codereview.chromium.org/12221064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14001 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
- actually release handles kept by compilation info when compilation completes.
- do not use parallel recompilation on single core CPUs.
- artificially delay parallel recompilation for debugging.
- fix outdated assertions wrt optimization status.
- add "parallel" option to %OptimizeFunctionOnNextCall.
R=jkummerow@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/12442002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13827 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The patch is based on the previous one that was rolled out: https://code.google.com/p/v8/source/detail?r=12985
On Linux sampling for CPU profiler is initiated on the profiler event processor thread, other platforms to follow.
CPU profiler continues to use SamplingCircularQueue, we will replave it with a single sample buffer when Mac and Win ports support profiling on the event processing thread.
When --prof option is specified profiling is initiated either on the profiler event processor thread if CPU profiler is on or on the SignalSender thread as it used to if no CPU profiles are being collected.
ProfilerEventsProcessor::ProcessEventsAndDoSample now waits in a tight loop, processing collected samples until sampling interval expires. To save CPU resources I'm planning to change that to use nanosleep as only one sample is expected in the queue at any point.
BUG=v8:2364
Review URL: https://codereview.chromium.org/12321046
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13735 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes:
* Adding support for saving callee-clobbered double registers in Crankshaft code.
* Adding a new "HTrapAllocationMemento" hydrogen instruction to handle AllocationSiteInfo data in crankshafted stubs.
* Adding a new "HAllocate" hydrogen instruction that can allocate raw memory from the GC in crankshafted code.
* Support for manipulation of the hole in HChange instructions for Crankshafted stubs.
* Utility routines to manually build loops and if statements containing hydrogen code.
Review URL: https://codereview.chromium.org/11659022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13585 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- perform CPU profiler sampling in the sampler thread as we used to;
- skip sampling in the sampling thread if processing thread is running;
- only install SIGPROF handler when CPU profiling is enabled.
BUG=v8:2364
Review URL: https://codereview.chromium.org/11231002
Patch from Sergey Rogulenko <rogulenko@google.com> and Andrey Kosyakov <caseq@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12985 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When code objects in the heap for FUNCTIONs and OPTIMIZED_FUNCTIONs are marked by the GC, their prologue is patched with a call to a stub that removes the patch. This allows the collector to quickly identify code objects that haven't been executed since the last full collection (they are the ones that sill contain the patch). The functionality is currently disabled, but can be activated by specifying the "--age-code".
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/10837037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12898 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In more detail:
- Set observation bit for observed objects (and make NormalizedMapCache respect it).
- Mutation of observed objects is always delegated from ICs to runtime.
- Introduce JS runtime function for notifying generated changes.
- Invoke this function in the appropriate places (including some local refactoring).
- Inclusion of oldValue field is not yet implemented, nor element properties.
Also, shortened flag to --harmony-observation.
R=verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/11347037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12867 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We iteratively remove all dead Hydrogen instruction until we reach a fixed point. We consider an instruction dead if it is unused, has no observable side effects and is deletable. The last part of the condition is currently not very nice: We basically have to whitelist "safe" instructions, because we are missing more detailed dependencies and/or more detailed tracking of side effects.
We disable dead code elimination for now in our test runners, because we have tons of poorly written tests which wouldn't test anymore what they are supposed to test with this phase enabled. To get test coverage for dead code elimination itself, we should enable it on a few build bots. This is not really a perfect state, but the best we can do for now.
This patch includes a few const-correctness fixes, most of them were necessary for this CL.
Review URL: https://codereview.chromium.org/11088027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12697 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Safe operations are those that either do not observe unsignedness or have special support for uint32 values:
- all binary bitwise operations: they perform ToInt32 on inputs;
- >> and << shifts: they perform ToInt32 on left hand side and ToUint32 on right hand side;
- >>> shift: it performs ToUint32 on both inputs;
- stores to integer external arrays (not pixel, float or double ones): these stores are "bitwise";
- HChange: special support added for conversions of uint32 values to double and tagged values;
- HSimulate: special support added for deoptimization with uint32 values in registers and stack slots;
- HPhi: phis that have only safe uses and only uint32 operands are uint32 themselves.
BUG=v8:2097
TEST=test/mjsunit/compiler/uint32.js
Review URL: https://chromiumcodereview.appspot.com/10778029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12367 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Highlights of this CL:
* Introduced a new opcode in the deoptimizer for a setter stub frame.
* Added a global setter stub for returning after deoptimizing a setter.
* We do not need special deopt support for getters, although the getter stub creates an internal frame. The normal machinery works just right for this case, although we generate a stack that can never occur during normal fullcode execution. If this hurts us one day, we can parameterize and reuse the setter deopt machinery.
Review URL: https://chromiumcodereview.appspot.com/10855098
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12328 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in anticipation of the upcoming lexical global scope.
Mostly automatised as:
for FILE in `egrep -ril "global[ _]?context" src test/cctest`
do
echo $FILE
sed "s/Global context/Native context/g" <$FILE >$FILE.0
sed "s/global context/native context/g" <$FILE.0 >$FILE.1
sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2
sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3
sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE
rm $FILE.[0-9]
done
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10832342
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 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 adds the --verify-global-context-separation flag which can be used
to verify that no code object embeds pointers to more than one global
context after a full GC. It uses an object visitor that just performs
shallow traversal of the object graph spanned by one code object, and
breaks at points where application objects are encountered. So it will
not trip on cross-context leaks introduced by the application itself.
R=verwaest@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10830049
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12224 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently only simple getter calls are handled (i.e. no calls in count
operations or compound assignments), and deoptimization in the getter is not
handled at all. Because of the latter, we temporarily hide this feature behind a
new flag --inline-accessors, which is false by default.
Review URL: https://chromiumcodereview.appspot.com/10828066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
with more JS code that is loaded into the VM before writing the snapshot. Get
rid of the hard coded limit on the partial snapshot cache size. This change
disables most of the serializer tests for the snapshot build of the VM: It's
getting too complicated to support both booting from a snapshot and then
creating a new snapshot from the same VM or loading more code with another
snapshot in the same VM.
Review URL: http://codereview.chromium.org/10574013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11871 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is basically r11496, with the following changes:
* Set back pointers in maps (cherry-picked from r11528)
* Fixed size calculation in CopyInsert, as proposed by mstarzinger/rossberg
* DefineFastAccessor uses GetCallbackObject instead of GetValue (for __proto__)
* Put the code under a new flag, which is disabled by default
* Cut down the corresponding regression test
* Adapted bootup memory test, we actually only need a bit more memory on 64bit without snapshots, which can easily explained by more live maps lying around. Note that the snapshot variants are back to their previous limits.
Next steps: Investigate any performance degradationswith the flag enabled, and finally remove the flag when things are OK. Furthermore, GetCallbackObject should be merged into GetValue, the distinction is confusing and error-prone.
Review URL: https://chromiumcodereview.appspot.com/10445009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11651 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When an array index (in an array access) is a simple "expression + constant", just embed the constant in the array access operation so that the full index expression is (potentially) no longer used and its live range can be much shorter.
This is effective in conjunction with array bounds check removal (otherwise the index is anyway used in the check).
Review URL: https://chromiumcodereview.appspot.com/10382055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11596 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As a special case, for checks on index expressions with the form (expr + constant) if a smaller constant is checked later in the DT also eliminate the check.
Finally, if a larger constant is checked later in the same BB do the more general check (larger constant) earlier instead of the less general one.
This will not cause useless deoptimizations because, since we are in the same BB, all the checks would have been executed anyway.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10032029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11437 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
All module expressions, and all variables that might refer to modules,
are assigned interfaces (module types) that are resolved using
unification. This is necessary to deal with the highly recursive
nature of ES6 modules, which does not allow any kind of bottom-up
strategy for resolving module names and paths.
Error messages are rudimental right now. Probably need to track
more information to make them nicer.
R=svenpanne@chromium.org
BUG=v8:1569
TEST=
Review URL: https://chromiumcodereview.appspot.com/9615009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r10881 (0d25c61e).
Original commit message:
Generates inlined code for object allocation specific to the initial map
of the given constructor function. Also forces completion of inobject
slack tracking while crankshafting to finalize instance size of these
objects.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9569008
Patch from Daniel Kalmar <kalmard@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10890 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Turned all uses of 'const' into 'var'.
* Turned all uses of local 'function' into 'var'.
* Added a couple of missing toplevel 'var' declarations.
One consequence is that the properties on the builtin object are no longer
non-writable, and I had to adapt one test. Is that a problem?
Unfortunately, we cannot actually switch the library scripts to strict mode
by default, because that makes observable things like poisoned .caller properties
for library functions.
Also removed dead flag code in Compiler::Compile.
R=yangguo@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9415010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10758 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1. Instead of checking upfront and estimating a limit for the number, we
now are able to stop register allocation and bailout when we don't
have enough virtual registers.
2. GCed some out-dated flags from flag-definition.h
3. Simplified the interface from the Lithium builder to the
register allocator in lithium-*.cc: For uses and definitions, we
just record the virtual register number given by the Hydrogen value id.
For temporaries, we request a new virtual register from the allocator.
For fixed temps, we don't need to do anything.
4. Increased number of deoptimization entries to 16K. Eventually we
probably want to make this array grow dynamically.
Review URL: https://chromiumcodereview.appspot.com/9325019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10597 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
CPU-eating DOS attacks against node.js servers. Based on code from
Bert Belder. This version only solves the issue for those that compile
V8 themselves or those that do not use snapshots. A snapshot-based
precompiled V8 will still have predictable string hash codes.
Review URL: http://codereview.chromium.org/9086006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10330 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.
The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.
This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
ResolvePossiblyDirectEval, InitializeVarGlobal,
DeclareGlobals
The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache
Review URL: http://codereview.chromium.org/8417035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implementation extends the internal ObjectHashTable to be able to
hold arbitrary objects (e.g. Smis, Strings, ...) as keys by applying
specialized hashing functions to primitive types. Equality of keys is
defined using the internal SameValue function.
R=rossberg@chromium.org
BUG=v8:1622
TEST=mjsunit/harmony/collections
Review URL: http://codereview.chromium.org/8372027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9777 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The "live bytes" count is *really* a "marked black" count - i.e., the count of bytes *known* to be live.
Fix aggravating bug on X64 where assembler code used a value that was off
by a factor of 2^31.
Ensure that sweeping clears live-bytes. Added other missing increments.
Added print statements to trace live-byte modifications, under a flag.
Still a few cases of undercounting left.
(New issue to merge from GC branch to bleeding_edge)
Review URL: http://codereview.chromium.org/7970009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9338 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The preprocessor defines ENABLE_LOGGING_AND_PROFILING and ENABLE_VMSTATE_TRACKING has been removed as these where required to be turned on for Crankshaft to work. To re-enable reducing the binary size by leaving out heap and CPU profiler a new set of defines needs to be created.
R=ager@chromium.org
BUG=v8:1271
TEST=all
Review URL: http://codereview.chromium.org//7350014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Generate Mach-O in-memory objects for OSX. Dump locals and parameters
for non-optimized frames.
Unfortunately, it seems like more-recent-GDB on OSX there is a little
temperamental (eg, the version from macports will be missing symbols
from gdb-integration_g when the version included in xcode will not--
and this is with --gdbjit off).
Includes some Python scripts to make dealing with V8 values in gdb more
pleasant.
Patch by Luke Zarko.
Review URL: http://codereview.chromium.org/6995161
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8483 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Better support for 'polymorphic' JS and external arrays
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps and dispatches to shared stubs to perform the array operation.
Review URL: http://codereview.chromium.org/7036016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7935 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps. Currently, the only array types supported by the MEGAMORPHIC stub are fast elements for objects and JSArrays.
BUG=
TEST=
Review URL: http://codereview.chromium.org/6894003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7917 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add option armeabi to the SCons build for selecting the floating point variant to use. Also add externally defined CCFLAGS environment for all targets. Run test.py with option -S armeabi=hardfloat to test with hardfloat enabled.
Make selecting hardfloat EABI variant a build-time option instead of a runtime option.
Add a simple check of the EABI variant during V8 initialization to exit if the compilation was not configured correctly. The reason for this is that GCC does not provide a compile time symbol defining the EABI variant. This check is not fool-proof as it cannot check the compilation configuration used for the snapshot if any.
R=karlklose@chromium.org, erik.corry@gmail.com
BUG=none
TEST=none
Review URL: http://codereview.chromium.org//6905098
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Crankshaft is now the default on all platforms. This is the first
patch on the way to removing the classic code generator from the
system.
This time with no removal of the crankshaft flag. --nocrankshaft is
not at all the same as --always-full-compiler which I had used instead
for testing. That was what caused timeouts on the buildbots because of
repeated attempts to optimize hot functions. It makes sense to keep
the crankshaft flag in case you want to run only with the full
compiler and with no adaptive compilation.
R=vitalyr@chromium.org
Review URL: http://codereview.chromium.org/6759070
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7486 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This commit adds current working versions of assembler, macro-assembler,
disassembler, and simulator.
All other mips arch files are replaced with stubbed-out versions that
will build.
Arch independent files are updated as needed to support building and
running mips.
The only test is cctest/test-assembler-mips, and this passes on the
simulator and on mips hardware.
TEST=none
BUG=none
Patch by Paul Lind from MIPS.
Review URL: http://codereview.chromium.org/6730029/
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
