| Age | Commit message (Collapse) | Author |
|---|
|
After releasing APFv3, we realized that addressing memory from the top
could be simplified by adjusting a few details:
1) The APF interpreter now receives a single unified buffer containing
both the program bytecode and the data segment, unambiguously matching
the memory layout seen by installApfPacketFilter() and
readApfPacketFilter().
2) Data address zero coincides with the beginning of the APF program,
thus decoupling data addresses from the length of the program (which
could change between invokations of installApfPacketFilter()). This
simplifies the ApfGenerator by not requiring a data relocation step
similar to jump relocation.
3) For convenience, the interpreter pre-fills one volatile memory slot
with the total size of the APF buffer. The APF program can load this
value into a register to efficiently write near the end of the data
segment, thus allowing the program-data boundary to shift freely.
4) Negative addresses wrap around the end of the data buffer, such that
address -1 coincides with the last byte of the buffer.
5) The immediate offet of LDDW and SDDW are now sign-extended, such that
small negative offsets can be encoded as a 1-byte immediate. This,
combined with the modular addressing at (4), can be used to address
memory cells near the end of the data region with 2-byte opcodes.
Overall, the above changes allow building a simple 32bit counter with
a sequence more or less like this:
2 li R1, -4 ; R1 = -4 (last 32bit word of data)
1 lddw R0, [R1 + 0] ; R0 = old counter value
2 add R0, 42 ; Increment counter by some value
1 stdw R0, [R1 + 0] ; Write back the new value
Total: 6 bytes. Note how the above bytecode is independent of the actual
size of the program and data segments. To reduce bytecode size,
the counter increment sequence can be moved to an "IncrementAndDrop"
trampoline, taking only 2 bytes more than a direct jump to DROP:
2 li R1, -12 ; R0 = counter offset (third to last counter)
3 jmp CountAndDrop ; (could be 2 bytes if jumping nearby)
...
CountAndDrop:
1 lddw R0, [R1+0] ; R0 = old counter value
2 add R0, 1 ; Increment counter
1 stdw R0, [R1+0] ; Write back updated value
3 jmp DROP ; cya!
Adding a 1-byte INC instruction would make things a little nicer.
Change-Id: Ia9b25e49e127a48d7344ddc60b17c93d6421ab7d
Bug: 73804303
Test: runtest -x tests/net/java/android/net/apf/ApfTest.java
|
|
The new opcodes are LDDW (LoaD Data Word) and STDW (STore Data Word)
The only supported addressing mode is register-indirect with immediate
offset (register value + immediate value). Since there's a single
register bit encoded in the opcode, the other register is implicitly
used for the address operand. Hence, the following variations are
possible:
lddw R0, [1234]R1 ; R0 = *(R1 + 1234)
lddw R1, [1234]R0 ; R1 = *(R0 + 1234)
stdw R0, [1234]R1 ; *(R1 + 1234) = R0
stdw R1, [1234]R0 ; *(R0 + 1234) = R1
The immediate can also be specified to be length 0, making the memory
access equivalent to a plain register-indirect with no offset.
lddw R0, R1 ; R0 = *R1
lddw R1, R0 ; R1 = *R0
stdw R0, R1 ; *R1 = R0
stdw R1, R0 ; *R0 = R1
The encoding of the above instructions is a single byte, making a
typical counter increment more efficient, especially when the address
requires a multi-byte immediate:
ldh R1, 1234 ; address of our packet counter (3 bytes)
lddw R0, R1 ; load the counter from address 1234 (1 byte)
add R0, 1 ; increment the counter (2 bytes)
stdw R0, R1 ; write-back to data ram (1 byte)
Total: 7 bytes. Defining a separate INCW instruction would reduce the
above sequence down to 3 bytes (or 4 bytes if using an EXT opcode to
avoid wasting opcodes). This optimization can be added at a later point
if the data access patterns of production APF code justify it.
Bug: 73804303
Test: runtest -x tests/net/java/android/net/apf/ApfTest.java
Change-Id: Ibbd427e12987a1eef63b41d816af05a1bd9f9170
|
|
This reverts commit 6921f7406faceee05fe74bfd90b972c05017e850.
Reason for revert: broke JNI bindings used by framework tests
Change-Id: Ibbd38276da1cbabdd2229d93a1b212072cdc3cb9
|
|
The new opcodes are LDDW (LoaD Data Word) and STDW (STore Data Word)
The only supported addressing mode is register-indirect with immediate
offset (register value + immediate value). Since there's a single
register bit encoded in the opcode, the other register is implicitly
used for the address operand. Hence, the following variations are
possible:
lddw R0, [1234]R1 ; R0 = *(R1 + 1234)
lddw R1, [1234]R0 ; R1 = *(R0 + 1234)
stdw R0, [1234]R1 ; *(R1 + 1234) = R0
stdw R1, [1234]R0 ; *(R0 + 1234) = R1
The immediate can also be specified o be length 0, making the memory
access equivalent to a plain register-indirect with no offset.
lddw R0, R1 ; R0 = *R1
lddw R1, R0 ; R1 = *R0
stdw R0, R1 ; *R1 = R0
stdw R1, R0 ; *R0 = R1
The encoding of the above instructions is a single byte, making a
typical counter increment more efficient, especially when the address
requires a multi-byte immediate:
ldh R1, 1234 ; address of our packet counter (3 bytes)
lddw R0, R1 ; load the counter from address 1234 (1 byte)
add R0, 1 ; increment the counter (2 bytes)
stdw R0, R1 ; write-back to data ram (1 byte)
Total: 7 bytes. Defining a separate INCW instruction would reduce the
above sequence down to 3 bytes (or 4 bytes if using an EXT opcode to
avoid wasting opcodes). This optimization can be added at a later point
if the data access patterns of production APF code justify it.
Test: runtest -x tests/net/java/android/net/apf/ApfTest.java
Change-Id: I0ff919babd0b28058bdb984b227bda9c973c9907
|
|
This change involves no functional change to the APF interpreter.
Bug: 26238573
Change-Id: I64bbccd4223c340e7dd6794ad48df12aae6ab78f
|
