The vmStore implementation does not support storing data to other AML
entities such as Buffers, Fields or Regions. Support for these entities
will be included in a separate commit.
The current vmCopyObject implementation is as simple as possible for
now; only copying of strings and uint64 values is supported. This
matches the behavior of vmLoad.
Both vmLoad/Store functions support reading/writing to/from object
references following the ACPI spec rules about automatic dereferencing.
The helper only supports reading a subset of the available AML operands:
- constants (uint64, strings and bools; bools are auto-casted to uint64)
- local and method args
The implementation will recursively drill down into the operand values
till it reaches a value that can be mapped to a Go uint64 or string
type. For example, if arg0 contains a constant with the value "foo",
vmRead will recurse into the arg0 value and return "foo"
The execBlock method supports the various control flows defined by the
ACPI standard (next instr, continue, break and return). It is designed
so that it can be recursively invoked both AML methods and various
flow-altering opcodes (e.g. opIf, opWhile e.t.c.)
Due to the large number of opcodes that the AML VM needs to support,
using a long switch statement will not be as performant as setting up a
jump table due to the way that the go compiler generates code for long
switch statements on integer values (asm code indicates that binary
search is used to select the switch target).
For the time being, the populateJumpTable method will assign a
placeholder function to each jump table entry that just returns a
"opcode X not implemented error".
This commit updates the post-parse step so that:
- the visitor not longer recurses into method bodies. Since code inside
methods may potentially generate dynamic/scoped entities or even use
conditional invocations (if CondRefOf(X) { X(...) }), symbol resolution
will be deferred to the AML interpreter.
- parent-child relationships between entities are checked and updated if
not properly specified
Since the ACPI standard allows forward function declarations this step
is required so we can properly parse the argument list for function
invocations. Contrary to other AML entities, method invocations do not
include any sort of pkgLength information so unless we track the
expected argument count for each function, our parser will not be able
to figure out where the argument list ends.
