|
Authored by: mbouckaert on Monday, May 07 2012 @ 08:44 PM EDT |
Yep... Very established steps, over 40 years old:
Step 1 is like the 2nd pass of a typical compiler: From
abstract code to specific architecture
Step 2 is like relocatable code generation
Step 3 is like a traditional linker/loader
Step 4 is like a physical machine.
Step 4 running in a VM is pretty old -- B1700, CP/67.
Step 3 was already old hat, I think, on OS/360 PCP
Step 2 has existed for about the same amount of time.
Step 1 is one of the multiple ways of slicing the work of a
compiler (you can have quite a few passes - see IBM 1401's)
So what's left that's not prior art ?
---
bck[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Monday, May 07 2012 @ 08:47 PM EDT |
SO does that mean that once the code is run through dexopt on a particular
device once and the references are converted to pointers, the conversion from
symbolic reference to pointer has been done, so the conversion never happens on
that device again?[ Reply to This | Parent | # ]
|
|
Authored by: Ian Al on Tuesday, May 08 2012 @ 11:28 AM EDT |
Google prohibit dexopt on production devices. You are allowed to use it on an
engineering machine to create an image or in the JDK envoronment by calling a
version of the dexopt function from within one of two Java programs. That is the
process that Mitchell identified months ago in one of his expert reports.
If you are not convinced, I will dig out the link to the Android site, or you
could Google dexopt for yourself.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | Parent | # ]
|
|
|
|
|