|
Authored by: Anonymous on Friday, May 18 2012 @ 01:56 AM EDT |
"instruction containing a symbolic reference" should be construed
according to the standard computer science meaning that Dr. Mitchell ascribed to
it
You're way off base here. Dr. August's interpretation of this
phrase was the "standard computer science meaning". I've taken courses in
compilers and done work on VMs, and work with assembly language every day. So
please trust me when I tell you (for at least the third time now) that an
instruction does not "contain" anything but the bytes that it consists
of.
It "contains" an opcode, and it "contains" its operand(s)--in this case,
a one-byte field index. Nothing else. The instruction might "use" a symbolic
reference, and it might "make reference" to a symbol, but it certainly does not
contain a symbolic reference. There is no interpretation of those words
other than their literal interpretation, which makes any sense.
Dr. Mitchell
tried to bend it so that it meant practically the same thing as "instruction NOT
containing a symbolic reference". [ Reply to This | Parent | # ]
|
|
Authored by: Ian Al on Friday, May 18 2012 @ 05:17 AM EDT |
I chose that ambiguous title because it seems appropriate.
The patent
contains an irrelevant phrase: 'a memory containing intermediate form object
code'. It only makes sense to you lot because you are used to intermediate
stages in the compilation process. However, you all know that the final
'executable' has to be in the form of machine code instructions that can be
directly executed by the processor. Intermediate form object code cannot run on
a processor because it is not final form. You may consider that symbolic
references in intermediate form object code is a stunning new invention with no
prior art: I don't.
Dalvik and Java use virtual processors. Dalvik
requires the final executable to be in the form of a numeric value that indexes
to the software code that executes the virtual machine instruction. What Java
does is irrelevant. Judge Alsup told us so.
The issue is whether Dalvik
executes machine code with 'a processor configured to execute said instructions
containing one or more symbolic references by determining a numerical reference
corresponding to said symbolic reference'. This is nothing to do with a block of
machine code instructions searching for the value to which a named variable is
set. It is a processor that accepts machine code instructions directly in the
form of symbols rather than numeric values.
My example would be an
instruction using the mnemonic 'jmp' rather than a numeric value. Dalvik does
not do this. All intermediate compilation code that contains machine codes
expressed as symbolic references must be further processed into numeric values
in an index that points at the machine code instruction execution code. As far
as I can tell, that is carried out in the JDK by using the dx tool. This is
confirmed by Mr. McFadden when he explains how the existing numerical value
pointers in the .dex file being installed into a phone is short cut with a
pointer direct to the faster-operating instruction code.
Because the
Virtual Machine is more than a virtual processor it has to deal with method
calls.
Google: Others
can be inferred statically when
certain assumptions are made. What's
that?
Mr. McFadden: Those are
things dexopt can do.
Google:
For virtual method calls, replace method
index with vtable index. What's that,
replacing one index with another
index?...
Mr. McFadden: Very similar
to what we saw before. Similar
operation on method invocation.
Google:
For instance field get/put,
replacing field index with byte offset, is that the
same as TX-735? What is
that?
Mr. McFadden: Again, this is that
field@CCCC operand, replacing
that value with a byte offset into an
object.
Google: Again, what's
the difference between an index and an
offset?
Mr. McFadden: Almost
nothing. In this case, the index is into
a table; when I say offset, it's
usually a byte offset, but it's still pretty
much the same thing...
Google: A bit of code here: static linking
using dexopt. Explain what this is,
starting with line 1953 (rewrite
iget/iput).
Mr. McFadden: That's the
purpose of this function: rewrite
iget/iput. The note is just a reminder of how
the instruction is layed out in
memory.
Google: Line 1963, what's
that?
Mr. McFadden: That's
the name of the method, and the arguments
it takes.
This is dexopt
providing index table shortcuts for
method calls. iget/iput seems to be the
programming function that resolves the
method label and puts the pointer in the index
table. This is still static
optimisation by dexopt, but it is optimising the
method calls and those calls
have to have their text labels.
--- Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid! [ Reply to This | Parent | # ]
|
|
|
|
|