| ab35b50311951feea3782151dd5422ee944685c2 |
|
05-Jan-2012 |
Elliott Hughes <enh@google.com> |
Remove unsupported experimental opcodes.
External developers were starting to try to get themselves into trouble with
this stuff...
Change-Id: I2b03bfeaa8c98b6a994bc7924fc8dcf4e4d4f6cb
|
| a3394df8d7e5a6b2f1ee61d8a61b8baac255eff1 |
|
18-Feb-2011 |
Johnnie Birch <jlbirch> |
Update to allow x86-atom build for FI on Gingerbread
Also handles most TODO.txt items and contains some rewriting of the dispatch code.
Also adds a newline to the end of files that did not previously end with a newline.
Change-Id: Ifa627ac3d493447013524eb0be178b5b6d952612
|
| ac815100951522b19b3dc4f21100e57400a82267 |
|
28-Mar-2011 |
buzbee <buzbee@google.com> |
Fix x86-atom build
Fix an apparent merge problem in the x86-atom build. The
handler table still had a reference to the unused 0xF1 opcode
rather than the new OP_RETURN_VOID_BARRIER.
Change-Id: Iaa6329c15f7891fd793846a2d19979679aed9af2
|
| 0346e9dcddccd449c731e42ef83708ff6d8f0976 |
|
02-Mar-2011 |
Andy McFadden <fadden@android.com> |
Change invoke-object-init to /range form
The invoke-object-init instruction pretends to be a regular invoke
that only knows how to call Object.<init>. As such it always takes
one argument, and if we use the /range version we can specify the
"this" register with 16 bits instead of only 4.
Bug 3486699
Change-Id: I9ee4700c6935beee1dcbaa583b57befd33641414
|
| f8f23d402dc1eef107995b29ad4d91ee5b4e1c34 |
|
18-Feb-2011 |
Johnnie Birch <jlbirch> |
Update to allow x86-atom build for FI on Gingerbread
Also handles most TODO.txt items and contains some rewriting of the dispatch code.
Also adds a newline to the end of files that did not previously end with a newline.
Change-Id: I0cf3e77dc7bbf5ed7ec8538ef4d7d8740e296640
|
| 750d110b62cef538e193b6f91f5239b0c4b63ef1 |
|
12-Feb-2011 |
Andy McFadden <fadden@android.com> |
Rename invoke-direct-empty to invoke-object-init
The invoke-direct-empty instruction was introduced to remove the
overhead of calling the empty Object constructor. We now need it
to do some extra work on behalf of object construction, so it's
appropriate to change the instruction name to match the role it
fills rather than the more general role it was hoped to fill.
No functional changes.
Bug 3342343
Change-Id: I65dd6a2c00c99581c9a19b16fe193b70642c8fbb
|
| 90f15431b24a4004fab2db70f273155fcd1c42a4 |
|
03-Dec-2010 |
Dan Bornstein <danfuzz@android.com> |
Make opcode 00ff be called "dispatch-ff".
With this change, it's still implemented as an unused opcode, but
it's now ready for its new life!
Change-Id: Ic70d311704925067e47d87b657d133a792144e65
|
| c6cc1bd99ed071772829a39d44344cf949bf7458 |
|
02-Aug-2010 |
Johnnie Birch <johnnie.l.birch.jr@intel.com> |
Added new bytecodes for the x86-atom fast interpreter build.
Change-Id: Ided25c83d874eb02c78e01a0ea97dbb15ed30497
|
| fbdcfb9ea9e2a78f295834424c3f24986ea45dac |
|
29-May-2010 |
Brian Carlstrom <bdc@google.com> |
Merge remote branch 'goog/dalvik-dev' into dalvik-dev-to-master
Change-Id: I0c0edb3ebf0d5e040d6bbbf60269fab0deb70ef9
|
| 5387824f19033ed51a945fbc8c2b574998404b3d |
|
05-Mar-2010 |
Andy McFadden <fadden@android.com> |
Add instructions for volatile wide fields.
This adds four new instructions for accessing volatile wide fields (long
and double). The JLS requires that such accesses are atomic, but the
VM doesn't otherwise make guarantees about the atomicity of reads and
writes on 64-bit fields.
There are no behavioral changes. This just adds definitions for the new
instructions and a couple of tests. The current implementation is just
the non-volatile form of the instructions or a C stub, but since we're
not generating them it doesn't really matter yet.
Also:
- bumped Dalvik version to 1.3.0
- added a note to the x86-atom TODO list
For bug 1633591.
|
| 22d404a75a00cda0b0ebed1034c2808ba060b05f |
|
07-Apr-2009 |
Johnnie Birch <johnnie.l.birch.jr@intel.com> |
This is a contribution of x86-atom targeted assembly for the fast byte-code interpreter engine. This is an initial contribution with minimal optimizations that target the Intel ATOM processor. We expect to continuously improve this code. It is expected that there will be a discussion on the potential merge of this code and similar efforts (i.e. the mterp/x86 directory first included with cupcake). While this code is intended to target ATOM and not a generic X-86 processor, we were able to show the following improvements over the c-portable interpreter using the simulator build:
Build: TARGET_SIMULATOR: true
TARGET_BUILD_TYPE: release
TARGET_PRODUCT: sim
Environment: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz
PI = Portable Interpreter
IA = Fast IA Interpreter
Embedded CaffeineMark: (IA-PI)/PI: Average of 70% improvement on overall score
SPECjbb2000*: (IA-PI)/PI: Average of 37% improvement on raw score
SPECjvm98*: (PI/IA) Speedup: Mtrt: 1.2; Jess: 1.34; Compress: 1.57; Db: 1.46; Jack: 1.28
* SPECjbb2000 - 1 warehouse. Noncompliant - modified to run on Dalvik
* SPECjvm98 - Noncompliant - modified to run on Dalivk
|